Adaptive time_step in very stable conditions

Topics specifically related to any of the WRF runtime options, such as SST update, DFI, nudging, restarts, global runs, adaptive time step, ndown.exe, tc.exe, moving nest, etc.
Post Reply
bartbrashers
Posts: 77
Joined: Wed Aug 08, 2018 2:21 pm

Adaptive time_step in very stable conditions

Post by bartbrashers » Wed Mar 24, 2021 12:23 am

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: Select all

 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: Select all

# 
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: Select all

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
Last edited by bartbrashers on Wed Mar 24, 2021 12:32 am, edited 1 time in total.

bartbrashers
Posts: 77
Joined: Wed Aug 08, 2018 2:21 pm

Re: Adaptive time_step in very stable conditions

Post by bartbrashers » Wed Mar 24, 2021 12:31 am

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

Code: Select all

 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: Select all

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: Select all

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: Select all

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
Posts: 1456
Joined: Mon Apr 23, 2018 9:42 pm

Re: Adaptive time_step in very stable conditions

Post by Ming Chen » Mon Mar 29, 2021 5:50 pm

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.
WRF Help Desk

Ming Chen
Posts: 1456
Joined: Mon Apr 23, 2018 9:42 pm

Re: Adaptive time_step in very stable conditions

Post by Ming Chen » Mon Mar 29, 2021 5:51 pm

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.
WRF Help Desk

Post Reply

Return to “Special Running Options”