Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

use_adaptive_time_step leads to early stop of simulation

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

lkugler

New member
Hi,
I downloaded WRF-v4.3, compiled em_quarter_ss and set the runtime to 6 hours with use_adaptive_time_step = .true.
Why does the simulation stop after 3 hours with SUCCESS COMPLETE WRF?

This reminds me of the bug fix in WRF4.3 - it seems there still is a bug?!
Fix for instances of dt = 0 when using adaptive time stepping together and when step_to_output_time is set to true.


Thank you so much!

namelist.input
Code:
 &time_control
 start_year                          = 0001, 0001, 0001,
 start_month                         = 01,   01,   01,
 start_day                           = 01,   01,   01,
 start_hour                          = 00,   00,   00,
 start_minute                        = 00,   00,   00,
 start_second                        = 00,   00,   00,
 end_year                            = 0001, 0001, 0001,
 end_month                           = 01,   01,   01,
 end_day                             = 01,   01,   01,
 end_hour                            = 06,   00,   00,
 end_minute                          = 0,  120,  120,
 end_second                          = 00,   00,   00,
 history_interval                    = 30,   10,   10,
 frames_per_outfile                  = 1000, 1000, 1000,
 restart                             = .false.,
 restart_interval                    = 120,
 io_form_history                     = 2
 io_form_restart                     = 2
 io_form_input                       = 2
 io_form_boundary                    = 2
 /

 &domains
 use_adaptive_time_step              = .true.,
 target_cfl                          = 1.2, 1.2, 1.2,
 max_step_increase_pct               = 5, 51, 51,
 starting_time_step                  = 8,
 max_time_step                       = 12,
 min_time_step                       = 6,
 time_step                           = 8,
 time_step_fract_num                 = 0,
 time_step_fract_den                 = 1,
 step_to_output_time                 = .true.,
 time_step                           = 12,
 time_step_fract_num                 = 0,
 time_step_fract_den                 = 1,
 max_dom                             = 1,


Another similar issue I noticed: I get
Code:
forrtl: severe (71): integer divide by zero
when I run a modified em_quarter_ss with step_to_output_time = True, and I get SUCCESS COMPLETE WRF at 3 hours integration time, even when I set the simulation end time to > 3h.
 

Attachments

  • namelist.input
    5.1 KB · Views: 25
Hi,
I've run some tests and have identified the bug in the code, though I don't have the preferred solution yet (I'm running it by some colleagues). The issue is an equation in the adapt_timestep_em.F file that is based on the namelist variable "interval_seconds" and is looking for boundary condition times. Because we don't set this for idealized cases (nor do we have boundary conditions), it assumes the default value of 10800, which is 3 hours, and explains why it's stopping after 3 hours. Until the code is eloquently corrected, you can get around this by setting the value "interval_seconds" to the full length of your simulation (in seconds) in the &time_control section of the namelist.

Thank you for pointing out the issue! Please let me know your affiliation so that we can acknowledge you in the bug-fix release notes.
 
Thank you and your colleagues very much for the quickfix and keeping WRF running smoothly!
My affiliation is "University of Vienna" as it says in my signature.
 
Top