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