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

[GEMPAK #RVO-549444]: gempak 5.9.4 isssues

Tom,

Garp will attempt to use the datatype.tbl entry first (but won't find nam211 
there...
the name of the dataset is the first column, not trying to match in the file 
name
columns of datatype.tbl), and then would look for files that matched that 
string in the 
$grids directory defined at the top of the Garp_defaults file. When using that 
type of 
behavior of Garp without GEMPAK's file templates, all grids have to reside in a 
single top
level directory of $grids rather than subdirectories that the individual 
templates
allow.

Note that Garp_defaults uses the "HDS" environmental variable rather than
the "MODEL" environmental variable to define $grids. In Gemenviron, HDS is by 
default defined to be the same as $MODEL, but you don't have to use it that way.

To use data from case studies, if they are in a single flat directory structure
the way the COMET case studies were, you can just redefine MODEL and HDS to the
directory before launching Garp. Having A Garp_defaults file for the case to 
match
the modelkeys/modellabels expected for that case is fine. You can redefine 
GARPHOME
and GARP_PATH for the case study configuration.

I had a presenter at the Unidata workshop this summer that wanted to
display data from a 1997 case study, and of course, the current model names
and 4 digit yyyy names didn't match the old data file names that were used
back in those days. Garp just needs to have a Garp_defaults file that matches 
the
data naming for that case. You can have a datatype.tbl file for the case study 
as well, 
but that isn't necessary. The search order for finding files shown in cfl_tbop 
is:
 * The table is split into the path and filename, and the file is       *
 * located by searching in the following order:                         *
 *                                                                      *
 *      1. filename (local)                                             *
 *      2. path/filename (table as given)                               *
 *      3. $NCDESK/type/filename                                        *
 *      4. $NCSITE/type/filename                                        *
 *      5. $GEMTBL/type/filename 

A local datatype.tbl, or one placed in $NCDESK/config/datatype.tbl would 
override
the standard $GEMTBL/config/datatype.tbl file so you can use that NCDESK or 
NCSITE
variable in scripts which configure case studies.

Steve Chiswell
Unidata User Support



> 
> On Tue, 13 Feb 2007, Unidata GEMPAK Support wrote:
> 
> > The gribkey.tbl nam entries were changed to nam/YYYYMMDDHH_nam211,
> > nam212, etc. however, you do not have to change the Garp_defaults table
> > as the datatype.tbl file defines eta, eta211, eta212, eta104, eta215,
> > eta218 so that the $MODEL/nam/YYYYMMDDHH_nam###.gem will be found.
> >
> > The datatype.tbl file also defines the nam, nam12, nam20, nam40, nam80
> > keys (ncep's convention of model resolution rather than grid number) so
> > that your Garp file can use modelkeys of nam80 and nam40 (but not nam211
> > and nam212 since they aren't defined in the datatype.tbl file...though
> > you could add them).
> >
> > The GFS211 key is defines in the datatype.tbl file which is why that
> > worked for you.
> 
> Steve,
> 
> It seemed like the nam211 would have been covered by this entry in
> datatype.tbl:
> 
> NAM          $MODEL/nam                YYYYMMDDHH_nam211.gem
> CAT_GRD  SCAT_FCT   -1     -1     -1      OFF/0/0      4
> 
> but apparently not, and so this is what tripped me up.
> 
> > I tried to leave the Garp_defaults file with the eta model keys rather
> > than changing them to "nam" names since many users had the COMET case
> > studies, and those legacy names were important. You are correct that
> > since June 13, the NAM isn't the ETA model anm more, so using the NAM
> > convention is most correct.
> >
> > Anyhow, you should be able to get the Garp_defaults to work by using
> > either eta211 or nam80 and eta212 or nam40 (rather than nam211 and
> > nam212 as you have in modelkeys.tbl).
> 
> I used eta211 & eta212 as keys and they were found, although I kept the
> Nam 211 & 212 labels; it doesn't really matter what the labels are.
> 
> Now my question is: when using archival data rather than current data, how
> I can get garp to look in the archival data directory I have defined,
> rather than $MODEL?  (This is not a problem with other data types such as
> satellite, etc.  I described this problem in more detail in my first
> message to you of yesterday; see below.)
> 
> Tom
> -----------------------------------------------------------------------------
> Tom McDermott                         305 Lennon Hall
> Systems Administrator                 Email: address@hidden
> Earth Sciences Dept.                  Phone: (585) 395-5718
> SUNY College at Brockport             Fax: (585) 395-2416
> 
> 
> > Steve Chiswell
> > Unidata User Support
> >>
> >>
> >>> When clicking on eta, it would corespond to the
> >>> $GEMTBL/config/datatype.tbl template for the directory $MODEL/nam and
> >>> files with _nam211.gem.
> >>>
> >>> Garp should consult the datatype.tbl entry first, and only if it is not
> >>> found, would it use the old behavior of looking for the string in file
> >>> names under $MODEL....which if it found a directory of that string match
> >>> rather than a file, it would be the likely problem. Eg, thinking that
> >>> the $MODEL/nam (or $MODEL/eta) directory name was the file name to match
> >>> the key rather than a data file itself.
> >>
> >> Yes, I understand this, and why it would cause a problem.  However, it
> >> should find the datatype.tbl entry and not even default back to the old
> >> behavior.  And it did do this with avn==>gfs transition.
> >>
> >>> Can you provide me with your modelkeys an modellabels entries from
> >>> Garp_defaults if you modified them (and as you suspected, if you change
> >>> the name from "eta", then the fdf entries would have to be updated as
> >>> well, which might break older case studies unless you kept those fdf
> >>> entries too). Also, if you changed the ETA and NAM entries in
> >>> datatype.tbl can you send those along with the listing of contents of
> >>> $MODEL/nam?
> >>
> >> Yes, I understand the problem with the fdf directory names; I just have to
> >> write a script to change the directory name and then copy over our
> >> customized macros from the old installation.
> >>
> >> Here are the modelkey and modellabel entries from the 5.7.2p2
> >> Garp_defaults:
> >>
> >> modelkeys  :
> >> "thin,avn211,avn213,ecmf,eta211,eta212,mrf.gem,mrf202,ngm211,ruc211,ruc236,ukmet,ens"
> >> modellabels        :
> >> "AVN,AVN-211,AVN-213,ECMWF,ETA,MesoETA,MRF-EXT,US-MRF,NGM,RUC,RUC2,UK
> >> Met,Ensemble"
> >>
> >> and the corresponding entries for the 5.9.4 Garp_defaults:
> >>
> >> modelkeys  :
> >> "gfsthin,gfs211,nam211,nam212,mrf.gem,mrf202,ngm,ruc,ruc2,ensthin,ens038,ukmet,ecmf1"
> >> #
> >> modellabels        : "GFS thinned,GFS 211,Nam 211,Nam
> >> 212,MRF_EXT,MRF,NGM,RUC,RUC II,Ensemble,Ensemble 038,UK Met,ECMWF"
> >>
> >> I did not change the entries in 'datatype.tbl' for the same reason I
> >> didn't change 'gribkey.tbl'.
> >>
> >> Here is the directory listing for $MODEL/nam:
> >>
> >> -rw-r--r--   1 ldm      metbin   11918848 Feb  5 21:33
> >> 2007020600_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11926016 Feb  6 09:37
> >> 2007020612_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11942400 Feb  6 21:33
> >> 2007020700_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11926528 Feb  7 09:43
> >> 2007020712_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11917312 Feb  7 21:37
> >> 2007020800_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11892736 Feb  8 09:48
> >> 2007020812_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11856896 Feb  8 21:55
> >> 2007020900_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11794432 Feb  9 09:39
> >> 2007020912_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11780096 Feb  9 21:33
> >> 2007021000_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11773440 Feb 10 09:35
> >> 2007021012_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   11819520 Feb 10 21:35
> >> 2007021100_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   98533376 Feb 10 21:36
> >> 2007021100_nam212.gem
> >> -rw-r--r--   1 ldm      metbin   11850240 Feb 11 09:37
> >> 2007021112_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   98635264 Feb 11 09:38
> >> 2007021112_nam212.gem
> >> -rw-r--r--   1 ldm      metbin   80629760 Feb 11 15:34
> >> 2007021118_nam212.gem
> >> -rw-r--r--   1 ldm      metbin   11878912 Feb 11 21:34
> >> 2007021200_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   99264512 Feb 11 21:35
> >> 2007021200_nam212.gem
> >> -rw-r--r--   1 ldm      metbin   80948736 Feb 12 03:33
> >> 2007021206_nam212.gem
> >> -rw-r--r--   1 ldm      metbin   11900416 Feb 12 09:41
> >> 2007021212_nam211.gem
> >> -rw-r--r--   1 ldm      metbin   99073536 Feb 12 09:40
> >> 2007021212_nam212.gem
> >> -rw-r--r--   1 ldm      metbin   14328832 Feb 12 15:33
> >> 2007021218_nam212.gem
> >>
> >> As I said in my original message, the entries in gribkey.tbl and
> >> datatype.tbl appear to correspond, so why isn't Garp finding the nam
> >> files?
> >>
> >> Tom
> >> -----------------------------------------------------------------------------
> >> Tom McDermott                              305 Lennon Hall
> >> Systems Administrator                      Email: address@hidden
> >> Earth Sciences Dept.                       Phone: (585) 395-5718
> >> SUNY College at Brockport          Fax: (585) 395-2416
> >>
> >>> Steve Chiswell
> >>> Unidata User SUpport
> >>>
> >>>>
> >>>> On Tue, 23 Jan 2007, Unidata GEMPAK Support wrote:
> >>>>
> >>>>> Tom,
> >>>>>
> >>>>> Verify that your GEMDATA environmental variable is correctly defined
> >>>>> in Gemenviron (and/or Gemenviron.profile). Since NMAP2 shows no data in 
> >>>>> the
> >>>>> data source window, it sounds like either:
> >>>>> 1) The GEMDATA directory isn't correctly defined
> >>>>> 2) The $GEMTBL location isn't pointing to the current/correct version 
> >>>>> location
> >>>>>
> >>>>> Yes, the fdf directories do have to be renamed to match the model keys 
> >>>>> used.
> >>>>>
> >>>>> Since your decoders are creating the $GEMDATA/model subdirectories,
> >>>>> it seems like a problem with the environmental variables  for
> >>>>> the display environment.
> >>>>
> >>>> Steve,
> >>>>
> >>>> Let's separate the Garp problem from the NMAP problem and try to tackle
> >>>> the Garp problem first, as we use the former much more than the latter.
> >>>>
> >>>> The GEMDATA env var _is_ correctly defined in Gemenviron, and anyways has
> >>>> not changed since the last installation.  If it was not correctly 
> >>>> defined,
> >>>> Garp would not be able to find surface, upper air, radar, sat, etc. data.
> >>>> Nor would it be able to find all the other model data, except for NAM.
> >>>> And it is finding all these data types.  The only data not showing up is
> >>>> the NAM model.  This is what makes it so baffling.
> >>>>
> >>>> I discovered something while trying to set up Garp to use archival data
> >>>> for a student (something I've done countless times successfully).  In the
> >>>> Garp_defaults file I use for this data set, I define a $CASEDATA variable
> >>>> to point to where the archival data (in this case, just model--eta & 
> >>>> avn--
> >>>> and satellite data) resides, and then define $SATDIR and $grids as
> >>>> subdirectories of $CASEDATA.  While this worked fine as before for the
> >>>> satellite data, garp 5.9.4 ignored the $grids setting and looked for the
> >>>> models in the $MODEL directory where the current data resides.  It found
> >>>> not only the current GFS data, but also the current NAM data.  (But it
> >>>> used the old ETA and AVN labels, which makes sense as those were the
> >>>> labels defined in the archival Garp_defaults file).  I was only able to
> >>>> access the archival model data by using garp 5.7.2 .
> >>>>
> >>>> So on a hunch I copied today's 12Z nam211 files from the nam subdirectory
> >>>> up a level to the $MODEL directory.  The data now appears in the 
> >>>> drop-down
> >>>> menu with the correct 'Nam 211' label.  I don't know if this helps us 
> >>>> any,
> >>>> but it seems to point to the way that Garp 5.9.4 accesses the model data.
> >>>> Which in turn may indicate an anomaly with $GEMTBL entries.
> >>>>
> >>>> Tom
> >>>> -----------------------------------------------------------------------------
> >>>> Tom McDermott                            305 Lennon Hall
> >>>> Systems Administrator                    Email: address@hidden
> >>>> Earth Sciences Dept.                     Phone: (585) 395-5718
> >>>> SUNY College at Brockport                Fax: (585) 395-2416
> >>>>
> >>>>> Steve Chiswell
> >>>>> Unidata User Support
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've recently upgraded gempak from v. 5.7.2 to 5.9.4 and have been 
> >>>>>> having
> >>>>>> a few problems after installing.
> >>>>>>
> >>>>>> The new subdirectory feature in $MODEL seems to be working fine for the
> >>>>>> most part except that the NAM models are not showing up in the 
> >>>>>> drop-down
> >>>>>> menu for Garp.  The entries $GEMTBL/grid/gribgribkey.tbl for the ldm
> >>>>>> appear to correspond to the entries in $GEMTBL/config/datatype.tbl for
> >>>>>> Garp.  We are getting the 'nam211' and 'nam212' grids and those are the
> >>>>>> modelkeys for them.  The ECMWF model is also not showing up in the 
> >>>>>> menu.
> >>>>>> (I suppose the subdirectory names in fdf will also need to be renamed 
> >>>>>> to
> >>>>>> reflect the name changes from avn to gfs and eta to nam.)
> >>>>>>
> >>>>>> The other major problem is that there are no data displayed in the data
> >>>>>> source window in NMAP2.  Again, it seems like the entries
> >>>>>> $GEMTBL/config/datatype.tbl line up with the pattern actions in the
> >>>>>> $NAWIPS/ldm/etc/tempalates files.
> >>>>>>
> >>>>>> Tom
> >>>>>> -----------------------------------------------------------------------------
> >>>>>> Tom McDermott                          305 Lennon Hall
> >>>>>> Systems Administrator                  Email: address@hidden
> >>>>>> Earth Sciences Dept.                   Phone: (585) 395-5718
> >>>>>> SUNY College at Brockport              Fax: (585) 395-2416
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Ticket Details
> >>>>> ===================
> >>>>> Ticket ID: RVO-549444
> >>>>> Department: Support GEMPAK
> >>>>> Priority: High
> >>>>> Status: Closed
> >>>>
> >>>>
> >>>
> >>>
> >>> Ticket Details
> >>> ===================
> >>> Ticket ID: RVO-549444
> >>> Department: Support GEMPAK
> >>> Priority: High
> >>> Status: Closed
> >>>
> >>>
> >>
> >>
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: RVO-549444
> > Department: Support GEMPAK
> > Priority: High
> > Status: Closed
> >
> >
> 
> 


Ticket Details
===================
Ticket ID: RVO-549444
Department: Support GEMPAK
Priority: High
Status: Closed