Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Adaptive time_step in very stable conditions

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

bartbrashers

New member
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:

Code:
 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):

Code:
# 
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:

Code:
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
 
For a different test using WRF-4.2.2, I used this block:

Code:
 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:

Code:
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:

Code:
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:

Code:
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?
 
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.
 
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.
 
Top