Adaptive time_step in very stable conditions

[bartbrashers]

I'm running WRF-4.1.5 using 12/4/1.33 km nested domains to simulate central Alaska in the wintertime. There are strong surface-based inversions observed from time to time, and I would like to use adaptive time stepping so it can speed up when possible.

From my namelist.input:

 use_adaptive_time_step              = .true.,
 step_to_output_time                 = .true.,
 adaptation_domain                   = 2,
 target_cfl                          =  1.2,   1.2,   1.2,   1
 target_hcfl                         =  0.8,   0.8,   0.8,   
 max_step_increase_pct               =    3,     3,     3,     
 starting_time_step                  =    9,     3,     1,   
 max_time_step                       =   36,    12,     4,   
 min_time_step                       =    9,     3,     1,    
 min_time_step_den                   =   10,    10,    10,

So I'm starting with a short time step of 9 seconds, hoping it would speed up. It starts out fine (lines from rsl.error.0000):

# 
Timing for main (dt=  1.00): time 2019-12-04_12:00:01 on domain   3:    4.95056 elapsed seconds
Timing for main (dt=  3.00): time 2019-12-04_12:00:03 on domain   2:   16.95529 elapsed seconds
Timing for main (dt=  9.00): time 2019-12-04_12:00:09 on domain   1:   49.07186 elapsed seconds

But it fairly rapidly slows down to a crawl:

Timing for main (dt=  0.14): time 2019-12-05_14:29:57 on domain   3:    1.03875 elapsed seconds
Timing for main (dt=  1.50): time 2019-12-05_14:29:55 on domain   2:   13.15375 elapsed seconds
Timing for main (dt= 36.00): time 2019-12-05_14:29:24 on domain   1:  323.18585 elapsed seconds

d01 is OK at 36 seconds, but d02 and especially d03 (1.33km) has slowed down to the extreme. I realize that when using adaptive time stepping, the ratio of the time step is not required to be 3, like it is normally.

I picked adaptation_domain = 2 because I was getting CFL errors in steep terrain gradient areas in the 4km domain. Should I set adaptation_domain = 3?

Is the d03 timestep stuck so small because I didn't use max_step_increase_pct = 51 for d03?

Any hints or "best practices" I can learn from?

Bart

 

[bartbrashers]

For a different test using WRF-4.2.2, I used this block:

 use_adaptive_time_step              = .true.,
 step_to_output_time                 = .true.,
 adaptation_domain                   = 3,
 target_cfl                          =  0.6,   0.6,   0.6,  
 target_hcfl                         =  0.6,   0.6,   0.6,  
 max_step_increase_pct               =    3,    51,    51,   
 starting_time_step                  =    6,     2,     1,   
 max_time_step                       =   36,    12,     4,    
 min_time_step                       =    1,     1,     1,  
 min_time_step_den                   =    1,    10,    10,

I can see in rsl.error.0000 that it starts out well:

Timing for main (dt=  1.00): time 2019-12-04_12:00:02 on domain   3:    0.76293 elapsed seconds
Timing for main (dt=  2.00): time 2019-12-04_12:00:02 on domain   2:   14.52228 elapsed seconds
Timing for main (dt=  6.00): time 2019-12-04_12:00:06 on domain   1:   38.47037 elapsed seconds

But right before it crashes with a CFL error I see:

Timing for main (dt= 36.00): time 2019-12-04_17:54:00 on domain   1:   15.51394 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:04 on domain   3:    0.79766 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:08 on domain   3:    0.78450 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:12 on domain   3:    0.79539 elapsed seconds
Timing for main (dt= 12.00): time 2019-12-04_17:54:12 on domain   2:    3.58542 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:16 on domain   3:    0.78342 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:20 on domain   3:    0.77055 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:24 on domain   3:    0.77852 elapsed seconds
Timing for main (dt= 12.00): time 2019-12-04_17:54:24 on domain   2:    3.54514 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:28 on domain   3:    0.78600 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:32 on domain   3:    0.76351 elapsed seconds
Timing for main (dt=  4.00): time 2019-12-04_17:54:36 on domain   3:    0.77421 elapsed seconds
Timing for main (dt= 12.00): time 2019-12-04_17:54:36 on domain   2:    3.54386 elapsed seconds
Timing for main (dt= 36.00): time 2019-12-04_17:54:36 on domain   1:   13.81003 elapsed seconds
Timing for main (dt=  1.20): time 2019-12-04_17:54:37 on domain   3:    0.79938 elapsed seconds
Timing for main (dt=  1.20): time 2019-12-04_17:54:37 on domain   2:    2.06521 elapsed seconds

And here's the CFL message:

d02 2019-12-04_17:54:24             7  points exceeded cfl=2 in domain d02 at time 2019-12-04_17:54:24 hours
d02 2019-12-04_17:54:24  MAX AT i,j,k:           200          199           38  vert_cfl,w,d(eta)=    5.358111       -19.34883       1.7999999E-02
[c22:37005] *** Process received signal ***
[c22:37005] Signal: Segmentation fault (11)
[c22:37005] Signal code: Address not mapped (1)
[c22:37005] Failing at address: 0xfffffffe07fa5094

I suppose it's possible the SegFault (Segmentation Fault) is unrelated to the CFL error.

Any suggestions?

 

[Ming Chen]

HI,
I think that time-step =6, 2, 1 could be too small. I would suggest that you try the default options:

starting_time_step(max_dom) = -1,-1, -1

which indicates that the model will use 6 * dx as the start_time_step. It will adjust the time step later based on target_cfl and max_step_increase_pct

Please try and see how this case works.

 

[Ming Chen]

Also, if the terrain is very steep, please increase the value of epssm probably from 0.1 to 0.5, which will increase the model stability.