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

[GEMPAK #RVO-549444]: gempak 5.9.4 isssues



Tom,

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

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.

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?

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