You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When use_adaptive_time_step = .true. for a WRF-ideal run, model will only integrate to a maximum of 3 hours (or shorter). It runs "successfully," just does not continue for runs with longer run times specified in namelist.
Found this bug when running test/em_convrad case. I assume it may hold for all WRF-IDEAL.
I verified the bug on two different computers: CISL/Derecho and the OSCER supercomputer at University of Oklahoma. Quite different compilers. Latest WRF version; haven't tried with older versions.
To Reproduce
Steps to reproduce the behavior:
Run one of the idealized test cases
Set "use_adaptive_time_step = .true." in namelist and try setting run time beyond 3 hours.
Model will "successfully" complete at 3 hours, despite end time settings in namelist.
The text was updated successfully, but these errors were encountered:
jhruppert
changed the title
Adaptive time step limits model integration time to 3 hours when running ideal
Adaptive time step limits model integration time to 3 hours when running WRF-ideal
Apr 11, 2024
@jhruppert Sorry for the late reply. But this should probably reported in the Forum. That said, let us know the version of the model you're using, if you are using 'step_to_output_time' option, and attach a namelist.input file. The other comment would be is adaptive time stepping really a good choice for idealized work? Yes, it probably can run a bit faster, and the change of time step can affect solution too. Just something to consider.
@jhruppert Thanks to Jeronimo Bande, we may have a fix for getting idealized cases running with adaptive time stepping. See PR-2106.. That reminded us the adaptive time stepping was never designed to work with idealized cases, for many reasons. For one thing, an idealized initial condition is much more homogeneous and the case can be integrated much more stably than a real-data case.
@jhruppert Actually since the adaptive stepping depends on the boundary file frequency, we can add interval_seconds namelist to namelist.input file for the em_convrad case and set it to a large value, which is greater than the entire forecast time (e.g. 3 hours or more). It will allow adaptive time stepping to work in that case case. When you're able to run, check the time steps used in the run. It is possible that they don't vary that much.
Describe the bug
When use_adaptive_time_step = .true. for a WRF-ideal run, model will only integrate to a maximum of 3 hours (or shorter). It runs "successfully," just does not continue for runs with longer run times specified in namelist.
Found this bug when running test/em_convrad case. I assume it may hold for all WRF-IDEAL.
I verified the bug on two different computers: CISL/Derecho and the OSCER supercomputer at University of Oklahoma. Quite different compilers. Latest WRF version; haven't tried with older versions.
To Reproduce
Steps to reproduce the behavior:
The text was updated successfully, but these errors were encountered: