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

unwanted wrfrst creation AFTER a restart (WRF 4.1.1)

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.

M

MikeZu

New member
Hi - I've got a problem with WRF 4.1.1. After a restart, it continues to create wrfrst files - even though I've changed restart_interval such that none should be created.

For example, an initial run has restart files written every 9 hours (restart_interval = 540). I restart the run using those files, and set restart_interval to some much larger value (ie, restart_interval = 3420). Unforunately, the restarted WRF run continues to create wrfrst files every 9 hours.

This is a problem because these take considerable time, and it's prolonging the run time signifcantly.

Any thoughts on how to fix this? Thanks!
 
OK, after investigating, I don't believe that it continues to write wrfrst files "every 9 hours" (from this example). It DOES write a set of wrfrst at 9 hours after the restart, but does not repeat this at 18, 27, 36, etc hours.

Just to be clear, if restart_interval was 360 in the initial WRF run (another example), then a set of wrfrst files will be written 6 hours after the continued WRF run is restarted. Even if restart_interval is set to some value much larger.

So not as big of a problem as I first feared, but it can still add 5+ minutes to the run time...
 
Hi,
If you haven't already, can you try to add 'override_restart_timers = .true.' to the &time_control section of the namelist and see if that makes a difference? Thanks!
 
kwerner said:
If you haven't already, can you try to add 'override_restart_timers = .true.' to the &time_control section of the namelist and see if that makes a difference? Thanks!
Click to expand...
I hadn't tried it (I didn't know the option existed), but I just did. It did the trick, but I'm curious about the ramifications. A web search led to some documentation from an older version:
Care must be taken when using namelist 'override_restart_timers'. If you use fdda and sst_update, and if you restart at a time which is not a data time, then the restart run could be wrong because it may use the wrong data for fdda and sst_update.
Click to expand...
I'm not using sst_update, but I am using fdda. I'm not 100% sure what is meant by the phrase "data time" - does that mean times aligned with the forcing data? I'm using GFS data at 3hr intervals. If I do restarts on those 3hr intervals (which I have been doing), am I ok?

Thanks!
 
Hi,
I'm not sure what the person means in that post that you found. This is the option we have always advised and to my knowledge, it has not led to any problems for users with restarts. Let us know if you find out differently! Thanks.
 
I haven't seen any issues, but then I have been doing my restarts at times that align with my input data (GFS) intervals, which seems to be what the document is suggesting to be good.

Also, FWIW, the text I quoted with the warning came from the DTC website, but it was specifically referencing WRF V3.3: https://dtcenter.org/wrf-nmm/users/overview/wrf_prev_updates/wrf_updates_v3.3.php

Thanks for the help!
 
Hi,
Thanks for sharing that link. That is a legit reference, so it is something to consider. As 3.3 code is pretty old now, hopefully that has been worked out since. I would recommend doing a few small tests to verify that everything looks okay. Please do let me know if you find issues with using "override_restart_timers" with fdda. Thanks.
 
You must log in or register to reply here.
Top