Skip to content
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

Adaptive Time Step #41

Open
Fergui opened this issue Oct 7, 2021 · 2 comments
Open

Adaptive Time Step #41

Fergui opened this issue Oct 7, 2021 · 2 comments
Labels
lowpriority Low priority issue newfeature New feature or request

Comments

@Fergui
Copy link
Member

Fergui commented Oct 7, 2021

WRF-SFIRE simulations sometimes crash because of a too large time step. That motivates the use of an adaptive time step for running fire-atmosphere simulations with WRF-SFIRE. The main parameters to control the adaptive time step are defined in the domains section and they are:

Parameter | Default | Definition
use_adaptive_time_step | .false. | T/F use adaptive time stepping, ARW only
step_to_output_time | .true. | if adaptive time stepping, T/F modify the time steps so that the exact history time is reached
target_cfl (max_dom) | 1.2,1.2 | vertical and horizontal CFL <= to this value implies no reason to reduce the time step, and to increase it
max_step_increase_pct (max_dom) | 5,51 | percentage of previous time step to increase, if the max(vert cfl, horiz cfl) <= target_cfl, then the time will increase by max_step_increase_pct
starting_time_step (max_dom) | -1,-1 | flag = -1 implies use 6 * dx (defined in start_em), starting_time_step = 100 means the starting time step
max_time_step (max_dom) | -1,-1 | flag = -1 implies max time step is 3 * starting_time_step, max_time_step = 100 means that the time step will not
min_time_step (max_dom) | -1,-1 | flag = -1 implies max time step is 0.5 * starting_time_step, min_time_step = 100 means that the time step will not
adaptation_domain | 1 | default, all fine grid domains adaptive dt driven by coarse-grid; 2 = Fine grid domain #2 determines the fundamental adaptive dt.

A WRF-SFIRE adaptive time step test was performed in Cheyenne: /glade/u/home/angelfc/project/WRFx/wrfxpy/wksp/wfc-adaptive-test
The results need to be tested and validated against the same simulation but without adaptive time step also in Cheyenne here: /glade/u/home/angelfc/project/WRFx/wrfxpy/wksp/wfc-from-web-2021-09-26_15-15-35-2021-09-26_12:00:00-48

@janmandel
Copy link
Member

janmandel commented Oct 8, 2021

We need to find out what is the actual time step value, then, if it is not dt, use it in place of dt, and fix all places that compute itimestep*dt

WRF users guide does not say anything about what the time step variable is, only talks about the namelist.

dt is computed in dyn_em/adapt_timestep_em.F and eventually copied to grid%dt

Because of insufficient accuracy of floats, time is an object TYPE(WRFU_Time), which is based on ESMF time. The clock is stored in each domain and can be accessed by function frame/module_domain.F/domain_get_current_time and domain_get_sim_start_time. Time since the beginning of the run in float seconds can be retrieved subtracting the two and converting by function dyn_em/adapt_timestep_em.F/real_time. There are routines in share/module_date_time.F to convert WRFU_Time time object to string and vice versa.

Using SFIRE with adaptive time step should work except prints, which currently use itimestep*dt, as long as the step is not too large to violate stability conditions for the level set method. This was never a problem in real computations because the vertical CFL condition is more strict. Currently the level method just prints a warning should that happen. This may change with adaptive time step. Also, I think there used to be a loop in driver to do multiple fire model steps per atmosphere step but it was not needed and got deleted at some point.

@Fergui Fergui added the newfeature New feature or request label Jun 25, 2023
@Fergui
Copy link
Member Author

Fergui commented Jun 25, 2023

Need to upgrade to the current timekeeping API because time step number * dt is obsolete and may go away in future releases of WRF.

@Fergui Fergui added the lowpriority Low priority issue label Jun 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lowpriority Low priority issue newfeature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants