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

20021024: Gempak data file structure

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20021024: Gempak data file structure
  • Date: Fri, 25 Oct 2002 10:02:33 -0600
>From: ldm <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200210242232.g9OMWRq14272

>Steve,
>  Thanks for all the help getting Gempak installed.  You were correct, the
>osf directories were owned by root, and once we changed that to Gempak, it
>installed fine.  Now that Gempak is in, I need to point the Gempak
>programs to the data, which are being ingested on another box.  Since we
>have an NFS mount networked system, can I point Gempak to the file
>structure on teh machine running LDM?  If I point back
>to the current LDM machine, where do I set the pointer from?  I couldn't
>identify the top of the data directory tree in the Gempak installation.
>  Ultimately we will have one machine running LDM and Gempak for real-time
>analyses, and another machine running Gempak and MM5 and several other
>modeling programs using archived data.
>
>Thank you,
>Nancy 
>

Nancy,

All your workstations can share the data via NFS regardless of machine
architecture.

Typically, your LDM will decode GEMPAK data on the ingest machine
under ~ldm/data/gempak. The ~ldm/data directory under LDM is often
a line to a separate disk partition (since you usually want to
do system backups of your LDM configuration, but not the actual
data which is allways coming in). So, for example assume ~ldm/data is
a link to /export/data on the ingest machine, and your other
lab machines mount that partition as /data. I would typically suggest
creating a link from /data to /export/data on the ingest machine so
that all your machines could define GEMDATA as /data/gempak.

The $NAWIPS/ldm/etc/ directory has the pqact entries I use here.
All the decoders reference the data/gempak/.... path relative to
the LDMHOME directory (by default, the LDM always treats relative paths
in pqact as being under $LDMHOME unless overridden by the -d option
to pqact in your ldmd.conf file.

If you follow the same directory hierarchy for your archive data, then
users generally will only have to redefine a few environmental variables
in order for GEMPAK to find the old data.

For instance, in Gemenviron, $MODEL is generally defined as $GEMDATA/model. 
The $GEMTBL/config/datatype.tbl file provides file name aliases using
the $MODEL variable, so that your realtime data for eta211 might be in
$GEMDATA/model/yyyymmddhh_eta211.gem. Then, to have the programs find your
archived data, you might define GEMDATA to be /case##/gempak instead of
/data/gempak so that your $MODEL would be /case##/gempak/model. 

Generally, most of the data sets can be redirected using the environmental
variables $GEMDATA, $MODEL, $SAT, $RAD and $NTRANS_META (for comet cases that
provide ntrans meta files).

Steve Chiswell