[wrfems] Crashing Problem Using Adaptive Time Step

[Case, Jonathan (MSFC-ZP11)[ENSCO INC]]

Hi Don,

I have been using the adaptive timestep for a central American, nested domain (12km outer, and 2 inner 4km nests) for months without any instability crashes.  At one point, I had some problems with the adaptive timestep, so I went right to the source which was a paper that Todd Hutchinson (adaptive timestep author) presented at the WRF User's Workshop a few years ago.  

In his extended abstract, he suggested a target_cfl of 1.1, which is what I use on my central American domain.  I start out with a timestep of 6(delta-x), with a maximum timestep allowed of double the original.  The minimum timestep I keep as -1, so it automatically determines it.  I'm also slightly more conservative by limiting the max step increase percent.  

So in my namelist.input, I have:
 target_cfl                 = 1.1, 1.1, 1.1
 max_step_increase_pct      = 4, 4, 4
 starting_time_step         = 72, 72, 72
 max_time_step              = 144, 144, 144
 min_time_step              = -1, -1, -1

I hope this helps,
Jon Case (NASA SPoRT)

-----Original Message-----
From: wrfems-bounces at comet.ucar.edu [mailto:wrfems-bounces at comet.ucar.edu] On Behalf Of Donald Van Dyke
Sent: Tuesday, February 07, 2012 6:17 PM
To: WRF Model ListServ
Subject: [wrfems] Crashing Problem Using Adaptive Time Step

Hi List/Bob,

I am relatively new to the WRF-EMS, but I've got a problem that I don't 
really understand.  I am taking over WRF duties from a fellow forecaster 
who is moving on to another office, and in order to prepare for that, I 
have taken our local WRF setup at the office and duplicated it on my 
personal laptop.  We have the standard Red Hat setup in the office with 
V3.2.1.5.34.beta of the EMS, but my laptop is running Ubuntu 10.10, 
64-bit.  I ran the WRF-ARW a bit as a graduate student, so I have some 
previous familiarity with the WRF, although I wouldn't call myself an 
expert by any means.  Having this familiarity, I knew that the adaptive 
time-stepping option might be a way to shave some run time off of our 
current setup, which currently uses the Auto_S option.  Unfortunately, 
the runs crash relatively frequently on my laptop using the adaptive 
time-step option.  I have not tried it in our setup at the office 
because I don't want to risk crashing issues at the office until I have 
things completely stable on my laptop first.  I would say the runs crash 
about 75% of the time on my laptop with adaptive time-step enabled.  The 
error in the log files is the dreaded segmentation fault with no 
additional information about the crashes that I could find in the logs.  
However, I have had no crashes so far with the exact same runs when I 
switch back to Auto_S.  Whenever a crash happens with adaptive, I tinker 
with the TARGET_CFL and MAX_STEP_INCREASE_PCT options until I'm able to 
get a successful run for a particular case in real-time.  Then typically 
the next real-time case will crash, and I will do some more tinkering 
until I can get that one to run successfully as well.  Eventually I 
started to realize that this might be futile (I had the TARGET_CFL all 
the way down to 0.65 and it was still crashing).  I then decided to try 
out a case that I thought would definitely crash the adaptive (March '93 
superstorm) and tinker with that case until I got it to run in my hopes 
that if that particular case would run, then anything would run.  To my 
surprise, the March '93 superstorm case ran all the way through on the 
first try with my adaptive settings, only to have the next, much calmer 
real-time case crash again with those exact settings.  I am attaching 
the logs from an example crashing case as well as my sysinfo.txt 
information.  I'd like to eventually get adaptive working consistently 
if possible because when it does work, it shaves the run time on my 
laptop for our operational domain down from about 3 hrs, 45 minutes 
using Auto_S to about 2 hrs, 5 minutes using adaptive.  That's a pretty 
big improvement in my opinion, and if something similar happened on our 
setup at work, then it might open the door for either a bigger domain or 
increased resolution on our operational runs.

If anyone has any suggestions or ways to fix this issue, I would be very 
appreciative.  Thanks!

Don @ WFO Tallahassee