-
Notifications
You must be signed in to change notification settings - Fork 686
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the source of the dt=0 error when using adaptive time step in em_b_wave ideal test case #2106
base: release-v4.6.1
Are you sure you want to change the base?
Conversation
…dealized cases Restrict the remaining time until the next boundary control to be greater than 0 in order to correct the dtInterval.
Could you modify the description to say what kind of case this solves the problem for. |
Problems with the precision of the time_to_output calculation cause errors in setting the correct time step at output time and final time in the em_b_wave ideal test
Fix the dtInterval adjunstment on output time using adaptive and
The regression test results:
|
@JeroBnd Thanks for the patch. Mentioning about boundary file frequency gives me the following idea: since we don't specify BC interval in the idealized case, the default value for interval_seconds (i.e. the boundary file interval) is 3 hours or 10800 sec. So adding this namelist to namelist.input file and set it to a very large value (e.g. 433000 sec, which is greater than 5-day forecast time) allows adaptive time stepping to work in the em_b_wave case. Also importantly, if you look at the time step it actually takes in the run, there is no change in time stepping. So why use adaptive time stepping? |
@weiwangncar, yes this work-arround will work but its not very elegant and intuitive. Regarding the time step, in this particular case, the max_time_step is set equal to the start time, so it remains at 600 because both CFL and h_CFL stay below the limits (1.2 and 0.84). If you set a max_time_step greater or a starting_time_step lower, you will see the change in the time step. |
@weiwangncar, if you use a large max_time_step, like 2000, you will get a time step around 1200s. However, in the rsl.error file, you will see: "Timing for main (dt=******): time 0001......" This happens because it can't print a dt number larger than 1000. |
@JeroBnd But there are other rules governing the time stepping. In WRF it is roughly 6*DX (in km). So one should not use a time step much larger than 600 sec when the grid sizes are 100 km. |
@weiwangncar Indeed, there is a limitation in the code that does not allow fixed time steps beyond 6*DX (in km). However, I have never read a paper or article that theoretically limits it to that value (if you have one, please share it, I would love to read it). I believe this limit is a recommendation based on years of experience to avoid instability issues. When using the adaptive time step, this coded limitation no longer applies, and instead, the CFL limitation is used to increase the dtInterval to avoid instability. In the WRF manuals, it is recommended to set the maximum time step to 8xDX, and in Todd A. Hutchinson's paper, "An Adaptive Time-Step for Increased Model Efficiency," he use a maximum time step of 18xDX. |
@JeroBnd The large majority of users use fixed time-steps. In this case our recommendation is 5dx or 6dx. This is mostly limited by the vertical cfl condition w*dt/dz < 1. Convection and thin layers combine to give this limit. |
Fixed the source of the dt=0 error when using adaptive time step in ideal cases in em_b_wave ideal test case
Restrict the remaining time until the next boundary control to be greater than 0 in order to correct the dtInterval.
TYPE: choose one of [bug fix, enhancement, new feature, feature removed, no impact, text only]
KEYWORDS: adaptative, timestep, ideal
SOURCE: Jeronimo Bande (IDING SAS)
DESCRIPTION OF CHANGES:
Problem:
The adapt_timestep module is not prepared to handle this kind of idealized case. The algorithm uses the remaining time until the boundary condition is applied, with a counter that resets when the boundary condition is used.
In this idealized case, the counter starts with a value of 10800 (equivalent to 3 hours), but when the supposed boundary condition should occur, it doesn’t, and the counter continues decreasing into negative values, causing the simulation to terminate prematurely.
Solution:
Restrict the remaining time until the next boundary control to be greater than 0 in order to correct the dtInterval.
ISSUE:
Fixes #1560
Fixes #2103
Fixes #2036
LIST OF MODIFIED FILES:
/dyn_em/adapt_timestep_em.F
TESTS CONDUCTED:
RELEASE NOTE: Fix adaptative time step for ideal cases.