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

[GEMPAK #RVO-549444]: gempak 5.9.4 isssues

> 
> On Mon, 12 Feb 2007, Unidata GEMPAK Support wrote:
> 
> > Check the modelkeys you are using in Garp_defaults. The Garp_defaults
> > had the key "eta" associated with the label "Eta 211". It sounds like
> > you changed the label at least to NAM 211 (did you change the model key
> > also?).
> 
> Steve,
> 
> I changed the modelkeys (and modellabels accordingly) from eta211 & eta212
> to nam211 & nam212.  I also changed avn211 to gfs211.  The reason being,
> that the outpupt grid file names in $GEMTBL/grid/gribgribkey.tbl changed,
> so I had to change the labels in order for the files to be found by Garp.
> I really didn't have any choice (did I?), unless I wanted to modify the
> entries in gribkey.tbl, which I thought would be a recipe for trouble and
> likely to introduce all sorts of incompatibilities.  So I changed
> modelkeys instead.

Tom,

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.

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).

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