[Wrf-users] Tests with adaptive time step in WRF-ARW (v3)
Hutchinson, Todd
thutchinson at wsi.com
Tue Jun 24 08:04:37 MDT 2008
Breogan,
Having a time-step at 150s in the 4km domain certainly would cause problems. I'm not sure how it is getting to be so big. But, we can make some changes to limit the time-step. So, I would suggest the following:
In the Registry.EM file, change the following variables so that they are domain dependent:
min_time_step
max_time_step
target_cfl
max_step_increase_pct
starting_time_step
So, your namelist should look like:
rconfig integer time_step namelist,domains 1 - ih "time_step"
rconfig integer time_step_fract_num namelist,domains 1 0 ih "time_step_fract_num"
rconfig integer time_step_fract_den namelist,domains 1 1 ih "time_step_fract_den"
rconfig integer min_time_step namelist,domains max_domains -1 h "min_time_step"
rconfig integer max_time_step namelist,domains max_domains -1 h "max_time_step"
rconfig real target_cfl namelist,domains max_domains 1.2 h "target_cfl"
rconfig integer max_step_increase_pct namelist,domains max_domains 5 h "max_step_increase_pct"
rconfig integer starting_time_step namelist,domains max_domains -1 h "starting_time_step"
rconfig logical step_to_output_time namelist,domains 1 .false. h "step_to_output_time"
Then, in your namelist.cfg file,
min_time_step = 216,72,24
max_time_step = 540,180,60
target_cfl = 1.2, 1.2, 1.2
max_step_increase_pct = 5, 51, 51
starting_time_step = 216,72,24
The above numbers are similar to what we've found to be best in doubly nested 12km/4km simulations.
Further, for diagnosing time-step problems, you may find it useful to add a print out of the time step in your output. To do that, you could change a line in frame/module_integrate.F
from:
WRITE ( message , FMT = '("main: time ",A," on domain ",I3)' ) TRIM(message2), grid%id
to:
if (config_flags%time_step >= 0) then
WRITE ( message , FMT = '("main: time ",A," on domain ",I3)' ) TRIM(message2), grid%id
else
WRITE ( message , FMT = '("main (dt=",F6.2,"): time ",A," on domain ",I3)' ) grid%dt, TRIM(message2), grid%id
endif
Let me know how this goes.
Thanks,
Todd
________________________________
From: Breogan X. Gomez Hombre [mailto:breogan.gomez at meteogalicia.es]
Sent: Tuesday, June 24, 2008 8:13 AM
To: Hutchinson, Todd
Cc: edu.penabad at meteogalicia.es; wrf-users at ucar.edu; wrfhelp
Subject: Re: [Wrf-users] Tests with adaptive time step in WRF-ARW (v3)
Dear Todd,
My name is Breogan Gomez and I work in the same department as Eduardo Penabad, who has started this discussion. We have tried your suggestion, modifying the Registry and recompiling the code as wrfhelp have suggested, and the model still crashes. This are the parameters we have chosen for the adaptive time_step for our 36Km, 12Km, 4Km domain. As you can see this are fairly conservative.
time_step = 225,
[...]
use_adaptive_time_step = .true.,
step_to_output_time = .true.,
target_cfl = 1.1,
max_step_increase_pct = 5,51,51
starting_time_step = -1,
max_time_step = 475,
min_time_step = 180,
As you have suggested we had a look to the last lines before crashing. This are the values:
Timing for main: time 2008-06-24_06:23:45 on domain 1: 3.39700 elapsed seconds.
Timing for main: time 2008-06-24_06:26:23 on domain 3: 0.23600 elapsed seconds.
Timing for main: time 2008-06-24_06:26:23 on domain 2: 0.74010 elapsed seconds.
Timing for main: time 2008-06-24_06:29:01 on domain 3: 0.29760 elapsed seconds.
Timing for main: time 2008-06-24_06:29:01 on domain 2: 0.75270 elapsed seconds.
Timing for main: time 2008-06-24_06:31:40 on domain 3: 0.27950 elapsed seconds.
Timing for main: time 2008-06-24_06:31:40 on domain 2: 0.75810 elapsed seconds.
Timing for main: time 2008-06-24_06:31:40 on domain 1: 2.72560 elapsed seconds.
Timing for main: time 2008-06-24_06:34:18 on domain 3: 0.32230 elapsed seconds.
Timing for main: time 2008-06-24_06:34:18 on domain 2: 0.80300 elapsed seconds.
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN 11 7 NaN
As you can see model domain 3 (4Km) has reaches aproximated time step of 150 seconds! It could be possible that model will be blowing because the inner domains are reaching too high time-step values? Which yields to another question.
Are the time_steps from the inner domains limited by the "max_time_step" and "min_time_step" parameters? If so, are this values divided by the resolution ratio? If not, Could I modify the Regitry, in the same way I did for the "max_step_increase_pct", to select different "max_time_step" and "min_time_step" for each domain?
Finally, do you have any other suggestion we could try?
All the best
Hutchinson, Todd escribió:
Eduardo,
Glad to see that you are working with the adaptive time-step. As I'm sure you know, it is new in WRF3.0. We developed and have been using the adaptive time-step in operational forecasts with a modified version of WRF2.2 for quite some time. Our operational simulations consist of an outer 12km nest and an inner 4km nest. This configuration has been very stable for us. However, we have only done limited testing with three levels of nesting.
I'm interested to see the length of the time-steps just before the model crash. Could you post the last hundred or so "Timing for main" lines from the rsl.out.0000 file?
Have you set any parameters in the namelist file other than the use_adaptive_time_step setting?
I'd suggest that you add the following to your namelist file:
max_step_increase_pct = 5, 51, 51 (the default is 5,5,5)
This will limit the time-step of the outer nest from changing by more than 5%, but allow the time-step on the inner two nests to change by up to 51%. Since the inner nest(s) time steps must be evenly divisible into the outer nest time-step, with the default of 5,5,5, the time step on the inner nests will not increase unless the time-step on the outer nest changes.
Just FYI:
I believe the 'WOULD GO OFF TOP" lines that you see are a symptom of the model being unstable. I've seen these types of errors in several situations:
1) a couple of minutes into a simulation -- often this is caused by bad input data
2) later on during a simulation -- this is most often caused by a time-step problem, or bad boundary data.
________________________________
From: wrf-users-bounces at ucar.edu [mailto:wrf-users-bounces at ucar.edu] On Behalf Of Eduardo Penabad Ramos
Sent: Tuesday, June 17, 2008 11:37 AM
To: wrf-users at ucar.edu
Cc: 'wrfhelp'
Subject: [Wrf-users] Tests with adaptive time step in WRF-ARW (v3)
Hello!
we are running a setup of 3 nested grids with WRF-ARW (v3) over Galicia (NW Iberian Peninsula), with dx=36,12 and 4 km.
We are testing the adaptive time step with this grid configuration, and with the following set of physics:
Radiation: Longwave RRTM, Shortwave MM5-Dudhia
PBL: YSU (with sfclay: Monin-Obukhov from MM5 MRF)
Surface: 5 layer MM5 LSM
Cumulus: Kain-Fritsch
Microphysics: WSM6
With this setup we have experienced some problems related with Kain-Fritsch (we guess). After about 40-50 hours of simulation, error messages appear in the WRF output textfiles:
WOULD GO OFF TOP: KF_ETA_PARA I,J,DPTHMX,DPMIN
where NaNs appeared for DPTHMAX
We have tested with Betts-Miller-Janjic cumulus parameterization, and although no error messages appeared, wrfout files also have some NaNs inside.
Do you have any suggestions? Thanks in advance!
Eduardo Penabad
MeteoGalicia
________________________________
_______________________________________________
Wrf-users mailing list
Wrf-users at ucar.edu
http://mailman.ucar.edu/mailman/listinfo/wrf-users
--
Breogán Gómez Hombre
MeteoGalicia - Dpto. Investigación e Predición Numérica
Consellería de Medio Ambiente e Desenvolvemento Sostible
Xunta de Galicia
Área Central, Local 31-C
Polígono de Fontiñas. 15703 Santiago de Compostela
Tfno: (+34) 981 95 74 62
FAX: (+34) 981 95 74 66
www.meteogalicia.es <http://www.meteogalicia.es/> - breogangomez at meteogalicia.es <mailto:numerico at meteogalicia.es>
More information about the Wrf-users
mailing list