[wrfems] Qstns about using RUC13 for initialization and SPoRT LIS for Lands Surface

Robert Rozumalski Robert.Rozumalski at noaa.gov
Tue Feb 14 15:22:02 MST 2012


Hello Steve,


I just tested it and everything worked fine in the current beta release, so:

If you are attempting to initialize a simulation  with the 19Z run of 
the RUC you will need to make sure you are requesting HOURLY nam 
personal tiles.
Set  FREQFH = 01 in your "namptile_gribinfo.conf" file and BCFREQ  = 01 
in ems_autorun.conf files because  if FREQFH = 03 in the gribinfo file  
then
ems_prep will fail with the following error:

---------------------------------
     !  Warning: Only allowing 00, 03, 06, 09, 12, 15, 18, 21 UTC 
ruc13ha cycle times with namptile boundary conditions

     !  Hey, That's Not a Cycle Time!

        The 3 hour forecast frequency of the namptile boundary condition 
data set has reduced
        the number of ruc13ha cycle times available for initialization.

        And Mr. 19 UTC cycle time, you're not on the list!
-------------------------

Why?  Because you need a NAM personal  valid at each BC time.   If 
FREQFH = 03 and BCFREQ = 3 and your forecast is 30 hours as you stated,  
you need

     NAM fcsts valid at 22UTC (19 UTC + 3 hrs), 01, 04, 07, 10, 13, 16, 
19, 22, and 01 UTC

But since FREQFH = 01 ems_prep thinks NAM forecast files are only valid 
at integer multiples of 3hrs + cycle time (00, 03, 06, ... UTC)


There is the possibility that you are going beyond the period of 
available 1 hourly NAM files. When you started the run, probably at 20 UTC,
the available last available NAM cycle was from 12 UTC (ems_prep knows 
all). So the first BC file it would attempt to use would be the
8 hour forecast from the 12 UTC run.  Since your run goes for 30 hours 
you will need NAM forecast hours 8 through 38 for BC files
but the hourly NAM files stop at hour 36.  Your simulation is doomed.

Bob



On 2/14/12 2:36 PM, Steve Keighton wrote:
> Everything worked when I ran this just after 19Z, except it was trying 
> to download the 18Z namptile for the BC, and it tried several times 
> and eventually failed (it got the ruc13ha, and the SPoRT SST and LIS 
> data as well.  What's the proper annotation in the DSETS line to tell 
> it to go and find the previous version if it can't find what it thinks 
> is the current one?  Something like DSETS = ruc13ha%namptfile,previous  ?
>
> Thanks,
>
> Steve
>
> On 2/14/2012 1:16 PM, Robert Rozumalski wrote:
>> On 2/14/12 10:49 AM, Steve Keighton wrote:
>>> Thanks Bob. Since we run our WRF out to  30 hrs, I am assuming I 
>>> cannot use the RUC for BC but I can for initialization.  So, if my 
>>> DSETS line looks like this:
>>>
>>> DSETS = ruc13ha%namptile
>>
>> Yes, that should work.    Alternatively you can use "DSETS = 
>> ruc13ha%gfsptile".
>>
>> Bob
>>
>>>
>>> ...will that accomplish my goal to initialize with RUC13 but use NAM 
>>> for BC?
>>>
>>> Steve
>>>
>>> On 2/14/2012 12:21 PM, Robert Rozumalski wrote:
>>>> On 2/14/12 9:37 AM, Steve Keighton wrote:
>>>>> List, I'm in the category of just knowing enough to be dangerous 
>>>>> with playing around with WRF configurations, so have what may be a 
>>>>> couple of simple questions:
>>>> I'm all for the element of danger in local area modeling as it 
>>>> increases the feeling of gratification you receive when you've 
>>>> completed a simulation and nobody has lost an eye.
>>>>>
>>>>> 1) I've been hearing for some time (just dragging my feet to do 
>>>>> anything about it) that folks are getting some good success 
>>>>> initializing with the RUC13.  What is the preferred option for 
>>>>> this: ruc13ha (hybrid vert coord analysis only), ruc13hf (hybrid 
>>>>> fcst files), or ruc13pa (press coord analysis only).  I'm 
>>>>> initializing a new run every 3 hrs, but since the RUC is hourly I 
>>>>> figure I do not need the forecast data set, but not sure which of 
>>>>> the two analysis options would be best.  Related to this is the 
>>>>> appropriate command line in ems_autorun.conf file. We're currently 
>>>>> initializing with a LAPS hotstart, and using NAM12 boundary 
>>>>> conditions, so the line is DSETS = laps%tile12. Can I simply 
>>>>> change that to ruc13ha%tile12 if I still want to use the NAM for BC?
>>>>
>>>> A few issues:
>>>>
>>>>   1.  You should move away from using the NCEP NAM tiles for 
>>>> initialization in favor of the STRC personal tiles (ptiles), which 
>>>> should be smaller in size than the
>>>>        NCEP tiles and you don't have to worry about whether you 
>>>> have the appropriate tiles for your domain. It's all dynamic.
>>>>
>>>>        The ptiles are available for the NAM, GFS, and RUC
>>>>
>>>>        I'm also dropping NCEP tile support in the next EMS release
>>>>
>>>>   2.  You are better off using either the RUC hybrid forecast files 
>>>> (ruc13hf) or analyses (ruc13ha) for the lateral BCs than the 
>>>> pressure coordinate data set for a couple
>>>>         of reasons.  The pressure coordinate data set has fewer 
>>>> vertical levels than the hybrid data set and thus the 
>>>> initialization hour data set, RUC hybrid, needs to be
>>>>         thinned in the vertical so that the number of levels are 
>>>> the same as the BC data set.  This is automatically done by the EMS 
>>>> but it degrades the quality of the
>>>>         initialization.  In addition, the RUC pressure coordinate 
>>>> data set not not have the required soil moisture and temperature 
>>>> fields so you will need to get
>>>>         them from another data set through the "--lsm" flag.
>>>>
>>>>   3.   Your best option is to use the RUC forecast data for your 
>>>> BCs if running in real-time; otherwise, use the analyses for the 
>>>> initial and BC data.
>>>>
>>>>>
>>>>> 2) I'm already using the SPoRT SST as my primary choice for sea 
>>>>> sfc temps, but also want to use the SPoRT LIS for land surface 
>>>>> initialization vs. the NAM12.  At one point I tried simply 
>>>>> replacing LSM = tile12 with LSM = lis, but got errors and WRF 
>>>>> never ran so went back to tile12.  Could this be because the SPoRT 
>>>>> LIS has a limited domain and our WRF domain goes too far north?  
>>>>> Can anyone point me to details on what the SPoRT LIS domain is 
>>>>> (unless it does cover the CONUS, in which case my error must be 
>>>>> for another reason).
>>>>
>>>>    Any alternate SST data sets are specified in the SFC setting in 
>>>> ems_autorun.conf. The LIS skin temperature field is specified in 
>>>> the LSM field.  If the model domain extends
>>>>    beyond the areal coverage of the SST data, the preprocessor will 
>>>> use the default SST field from the initialization data set.  If the 
>>>> alternate LSM field is not large enough
>>>>    to cover the computational domain you should get an error.
>>>>
>>>>    I do have a test in the EMS to make sure the requested ptile 
>>>> data set covers the user's computational domain. I should probably 
>>>> add a similar test for all data sets.
>>>>
>>>>
>>>>    Bob
>>>>
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Steve
>>>>> -- 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> -- 
>>
>>
>> -- 
>> 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
>>
>
> -- 


-- 
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/20120214/a604b001/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 16833 bytes
Desc: not available
URL: <https://mailman.comet.ucar.edu/pipermail/wrfems/attachments/20120214/a604b001/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 16833 bytes
Desc: not available
URL: <https://mailman.comet.ucar.edu/pipermail/wrfems/attachments/20120214/a604b001/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 16833 bytes
Desc: not available
URL: <https://mailman.comet.ucar.edu/pipermail/wrfems/attachments/20120214/a604b001/attachment-0005.jpe>


More information about the wrfems mailing list