[wrfems] Major Temperature Problem

Robert Rozumalski Robert.Rozumalski at noaa.gov
Mon Mar 19 12:54:51 MDT 2012


It appears that your (and probably others) problem is related to the use 
of the adaptive timestep. If I run a simulation using your domain and 
configuration without
using the adaptive timestep, i.e., timestep = 5*dx (60s), everything is 
fine. When I turn on the adaptive time step method the near-surface 
fields are not updated.

This suggests that the tendencies are either being set to zero or they 
are not being added to the model perturbation fields, possible because 
the routine is not
being called.

I'm still working on a fix but in the mean time I would turn OFF the 
adaptive time step method.


On 3/19/12 12:16 PM, Don Van Dyke wrote:
> Thanks for your help.  Unfortunately, I only saved the grib files from 
> a failed run and didn't think to save the raw netCDF files, so I don't 
> have any failed netCDF files to look at for the moment.  The 12z run 
> today worked fine.  The only change we've made so far is to remove the 
> RUC from the initialization and just go with the NAMPTILE and 
> NAMPTILELSM with the sport SSTs for initialization.  If another run 
> fails, I'll try to get the netCDF copied off to look at.  I really 
> hope the cause is not the adaptive time-step somehow, since that's the 
> only way we can cram 4 runs per day on that computer.  However, we've 
> had the adaptive running for around a month now without any problems 
> at all.
> This issue brought up another question with the RUC data.  The RUC is 
> scheduled to be discontinued quite soon and replaced by the RAP.  Will 
> be able to use the RAP data right away, or will we need to wait for 
> another build and resort to using something other than RUC in the 
> meantime?  Thanks again!
> -Don
> Robert Rozumalski wrote:
>> Hello Don,
>> I've attempted to run a simulation using your configuration and got 
>> an interesting result, a segmentation fault after 23 hours.
>> Typically, a segmentation fault that occurs well into a simulation 
>> suggests a problem with the WRF code. It's possible that you
>> are getting the same errors without a seg fault since the fault will 
>> occur when the model is attempting to access a block of
>> memory on a system that is not accessible.  In your case it may be 
>> that wrf is accessing memory from an allowed area but
>> it's not the correct area, so the simulation continues.
>> For a failed run, take a look at the domain 2 WRF netCDF output files 
>> in the  wrfprd directory  with "ncview":
>>    %  ncview <netCDF file>
>>        Look at:   2D Vars -> 2T    (2m temp)
>> Start at the beginning of the run and work forward in time. Do you 
>> see anything unusual?
>> I suspect you will see an increase in the amount of white area with 
>> time. The white indicates that the data are bad.
>> I'm working  to determine the cause of the issue.
>> Bob
>> On 3/18/12 6:19 AM, Don Van Dyke wrote:
>>> Bob and others,
>>> We have developed a major temperature problem with our local WRF 
>>> here at WFO Tallahassee in the last 2 days.  For some unknown 
>>> reason, the surface and boundary layer temperatures are occasionally 
>>> not rising during the daylight hours for our inner 4 km nest.  We 
>>> run a 12 km/4 km configuration.  What is even stranger about this 
>>> problem is that the 12 km outer nest is just fine, and the problem 
>>> seems intermittent.  The nest is configured as a one-way nest 
>>> though, so I guess the problem must be isolated to the 4 km version 
>>> of the model somehow.  I first noticed this problem with the 12z 
>>> March 17th run, then the subsequent 18z and 00z runs were fine, then 
>>> the problem reappeared on the 06z March 18th run.  I've attached 
>>> some screenshots as an example.  On the 12z March 17th run, the 4km 
>>> model forecast areas of fog all day for the 18th with highs near 60 
>>> while the 12 km parent nest was normal with highs in the 80s.  I've 
>>> also attached the log files from the 06z March 18th run.   We've 
>>> never seen this happen before, and we're at a loss to explain why 
>>> it's only affecting the 4 km nest and not the 12 km run, and why the 
>>> problem seems to be intermittent.  Also, to my knowledge, nothing 
>>> has changed on our computer other than I recently added crons for 
>>> 00z and 12z runs.  (We previously only did 06z and 18z runs.)  
>>> However, I did not change anything with the model configuration.  
>>> This just suddenly started happening.  Thanks for any help anyone 
>>> can give!
>>> Don Van Dyke
>>> General Forecaster
>>> NWS Tallahassee, FL
>>> _______________________________________________
>>> wrfems mailing list
>>> wrfems at comet.ucar.edu
>> -- 
>> Robert A. Rozumalski, PhD
>> NWS National SOO Science and Training Resource Coordinator
>> COMET/UCAR PO Box 3000   Phone:  303.497.8356
>> Boulder, CO 80307-3000
>> ------------------------------------------------------------------------
>> _______________________________________________
>> wrfems mailing list
>> wrfems at comet.ucar.edu
> _______________________________________________
> wrfems mailing list
> wrfems at comet.ucar.edu

Robert A. Rozumalski, PhD
NWS National SOO Science and Training Resource Coordinator

COMET/UCAR PO Box 3000   Phone:  303.497.8356
Boulder, CO 80307-3000

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.comet.ucar.edu/pipermail/wrfems/attachments/20120319/fadbb00a/attachment-0001.html>

More information about the wrfems mailing list