[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000926: 20000925: 20000925: 20000925: Use of GEMPAK with case studies , RUC2 etc.



Glen,

The modelkeys section of Garp_defaults identifies unique strings
to search for in the filenames of data in the $HDS directory.
For example, assume uyou have the files:
 2000092600_eta.gem
 2000092600_mesoeta.gem

you would not want to use the modelkey "eta", since that string would
appear in both file names. However, if you used "_eta", it would
only match the first file. Then "mesoeta" or "_mesoeta" would uniquely
identify the second file. 

The default configuration I provide in the tarfile uses names as:
"eta211", "eta212", "ruc211", "ruc236", "maps255" etc since this
allows the string to identify the different grids that various
models appear on. I don't use the term "mesoeta" since in reality,
all 4 runs are supposed to be the same model now.

Now, whatever the unique strings you decide to use are, you can
define default garea and proj values specific to that model down
further in the config file, That way, you can have a default conus view for
211, and a global or nh view for the AVN for example. The string, as it appears
in the modelkey is the same string that will be searched for in the ..._proj
and ..._garea variables. And, the same string will be looked for as the name of
an FDF directory. If the string is not matched in the garea and proj variables, 
the
default_garea and default_proj will be used. And, if the FDF isn't matched,
then the default directory will be used as the pulldown grid diagnostic 
functions.
If you use _ruc for the key, then you would use _ruc_proj. If you use
ruc211 for the key, then ruc211_proj. The main point here is that, you
might be able to use the _ character as I showed in the eta example
above to create a uniquely matching string where otherwise the string
would match more than one dataset.

Since I never have used _ruc as one of my configurations, it won't be
in your fdf directories (unless someone on that end added it). You can
always create symbolic links for directory names. That way, you can use the
same directory of functions for ruc211 and ruc236. I prefer to use the
modelgridnumber pair now since so many models are available on multiple
projections. The exceptions I have are the AVN thinned grids (from the 8 octets)
which I just call "thin". That keeps them from being confused with the
avn003 grids on the OSO server.

I hope this clarifies the use of the modelkey. You are free to use any naming
convention you wish. Just be sure that your fdf and config file is
in sync.

Steve Chiswell



>From: address@hidden
>Organization: UCAR/Unidata
>Keywords: 200009261256.e8QCuUb22730

>
>
>OK, but what is the difference between the _ruc and the ruc?  I wonder why
>they were placed in?  (I think ROZ might have put them in since I did not.
>...) not sure though... Glenn
>
>
>
>
>Unidata Support <address@hidden> on 09/25/2000 05:11:50 PM
>                                                              
>                                                              
>                                                              
> To:      Glenn Rutledge/NCDC                                 
>                                                              
> cc:      Unidata Support <address@hidden>   
>                                                              
>                                                              
>                                                              
> Subject: 20000925: 20000925: 20000925: Use of GEMPAK with    
>          case studies, RUC2 etc.                             
>                                                              
>
>
>
>
>
>
>
>
>
>
>Glenn,
>
>The modelkey ruc211 would map to the fdf directory ruc211.
>If you use _ruc211, then you have to use _ruc211 macros as well.
>That also means that you have to have _ruc211_proj and _ruc211_garea
>down further in the file as well.
>
>Steve Chiswell
>
>
>
>>From: address@hidden
>>Organization: UCAR/Unidata
>>Keywords: 200009251942.e8PJgjb19033
>
>>
>>
>>Your right.  I did find the FOS notice for the RUC236, but that was for
>>"236 grid users" off the oso server I presume.  Concerning the RUC MAPS:
>>Here's my garpdefaults model keys:
>>modelkeys :
>>"_avn201,_avn202,_avn213,_eta212,_eta215,_ruc211,_mrf202,_ngm211"
>>modellabels    : "AVN 201,AVN 202,AVN 213,ETA 212,ETA 215,RUC 211,MRF
>>202,NGM 211"
>>
>>I've got "_ruc211", but I've still no option for the MAPS.... in the
>scalar
>>pulldown.  Also, I have no options in the vector pulldown.  In fact,
>>nothing pulls down at all.  It just says "General".  Any thoughts?  Thx,
>>Glenn
>>
>>
>>
>>
>>
>>
>>Unidata Support <address@hidden> on 09/25/2000 03:32:41 PM
>>
>>
>>
>> To:      Glenn Rutledge/NCDC
>>
>> cc:      Unidata Support <address@hidden>
>>
>>
>>
>> Subject: 20000925: 20000925: Use of GEMPAK with case
>>          studies, RUC2 etc.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>Glenn,
>>
>>I log all the products from NOAAPort. Haven't seen anythiing but RUC 211.
>>But, just like the 22km eta announcement, that won't affect NOAAPORT or
>FoS
>>output.
>>
>>Steve CHiswell
>>Unidata User Support
>>
>>
>>>From: address@hidden
>>>Organization: UCAR/Unidata
>>>Keywords: 200009251923.e8PJNYb17990
>>
>>>
>>>
>>>Thanks, Steve.  I'm sure to be contacting you when I try to get the case
>>>s/w working.   Also, I thought i saw a Julie hayes note about
>transmitting
>>>40km ruc on NOAAPort on Sep 6.  I'll track that down.    Thanks, Glenn
>>>
>>>
>>>
>>>
>>>Unidata Support <address@hidden> on 09/25/2000 03:15:14 PM
>>>
>>>
>>>
>>> To:      Glenn Rutledge/NCDC
>>>
>>> cc:      Unidata Support <address@hidden>
>>>
>>>
>>>
>>> Subject: 20000925: Use of GEMPAK with case studies, RUC2
>>>          etc.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Glenn,
>>>
>>>There is an example of ntl.case in the 5.4 distribution as:
>>>$NAWIPS/scripts/soosac/ntl.case.
>>>This isn't my script, but you can use it as a guide.
>>>ntl.case is just a script to set environmental
>>>variables for data locations (specific to each case) rather than
>>>the realtime data locations- before launching ntl. Typically,
>>>for the Unidata distribution, the environmental variables referenced
>>>in $GARPHOME/config/Garp_defaults are: $GEMDATA, $SAT, $NIDS, $HDS.
>>>Generally these are set when you source Gemenviron....however, since you
>>>would probably have each case in its own data tree, you would
>>>want to reset those locations for an ntl session- whereafter all the
>>>application launched from that ntl would inherit those values.
>>>You may want a separate ntl.case for each separate case study.
>>>
>>>RUC2 is not broadcast on NOAAPORT. Only the RUC 80km grid 211 is on
>>>NOAAPORT.
>>>The RUC2 grids are on the OSO ftp server in the /ncepe directories.
>>>
>>>All fdf functions which appear in the Garp pulldowns are defined in
>>>the $GARPHOME/fdf/scalar and vector directories. These functions are
>>>specific to
>>>the individual model names and the modelkeys used in
>>>$GARPHOME/config/Garp_defaults file.
>>>In the $GARPHOME/fdf/scalar(and vector) directories are modelkey specific
>>>directory
>>>names, eg:
>>>$GARPHOME/fdf/scalar/ruc211/general/MSLPress_mb_MAPS_Reduction
>>>
>>>The ruc211 directory is specific to the ruc211 modelkey used in
>>>$GARPHOME/config/Garp_defaults. If you name your grids something
>>>other than ruc211, then those directory names will have to
>>>reflect the model keys you are using. If there is no subdirectory under
>>fdf
>>>for the modelkey you are using, then the "default" directory is used-
>>>which won't have the MAPS specific macros.
>>>
>>>You can decode archived data into individual case trees for each data
>set.
>>>The locations that you chose to decode the data into should follow the
>>>same structure for each case, so that the $GARPHOME/config/Garp_defaults
>>>file locations can be represented by environmental variables I mentioned
>>>above.
>>>It is possible to use a different Garp_defaults file if necessary. THis
>>>file location is defined in the $NAWIPS/Gemenviorn files as GARP_PATH.
>>>If you need different data set names (model keys etc), then you could use
>>>your n
>>>tl.case script to redefine that variable as well for garp menus specific
>>>to that case.
>>>
>>>Steve Chiswell
>>>
>>>
>>>
>>>
>>>
>>>>From: address@hidden
>>>>Organization: UCAR/Unidata
>>>>Keywords: 200009251809.e8PI9bb15032
>>>
>>>>
>>>>
>>>>Steve,
>>>>Finally got the systems config right around here and garp is running.
>>>>Several questions:
>>>>
>>>>1) I thought there was a MAPS sfc mapping function for use with the RUC.
>>>>Only a SLP options is displayed on my system.  Do I have to set anything
>>>to
>>>>have it as an option in the model plan projection?
>>>>2) where is ntl.case?  Is that part of your distribution.  I can't seem
>>to
>>>>find it.
>>>>3) Speaking of the RUC. is there not a grib 236 or 7 grid now avbl. at
>>>40km
>>>>I've included that grid KWBH (i believe) in my paqct but it is not being
>>>>found.  Thanks
>>>>
>>>>4) I'm going to grab  raw NOAAPort data from our archives (yes, we are
>>now
>>>>finally archiving ALL noaaport NWS TG data), and I will send them to the
>>>>decoders for display in garp. (I'll set the clock with ntl.case).  Would
>>I
>>>>call the dc style decoders?  Or, which should I call (i.e., what
>>>>directories are they located?)    Thanks for your patience......
>>>>
>>>>Thanks,  Glenn
>>>>
>>>>
>>>
>>>*************************************************************************
>*
>>*
>>>Unidata User Support                                    UCAR Unidata
>>>(303)497-8644                                                  P.O. Box
>>>address@hidden                                   Boulder, CO
>>>-------------------------------------------------------------------------
>-
>>-
>>>Unidata WWW Service                        http://www.unidata.ucar.edu/
>>><
>>*************************************************************************
>*
>>*
>>>
>>>
>>>
>>
>>**************************************************************************
>*
>>Unidata User Support                                    UCAR Unidata
>>(303)497-8644                                                  P.O. Box
>>address@hidden                                   Boulder, CO
>>--------------------------------------------------------------------------
>-
>>Unidata WWW Service                        http://www.unidata.ucar.edu/
>><
>>**************************************************************************
>*
>>
>>
>>
>
>***************************************************************************
>Unidata User Support                                    UCAR Unidata
>(303)497-8644                                                  P.O. Box
>address@hidden                                   Boulder, CO
>---------------------------------------------------------------------------
>Unidata WWW Service                        http://www.unidata.ucar.edu/
><
>***************************************************************************
>
>
>