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

[GEMPAK #XTR-273547]: ldm ingest using exp. Gempak distro



> Say I'm currently running a production ldm environment with vers. x of
> Gempak decoders.
> I'd like to ingest with a different vers. xx of Gempak experimentally
> via the production ldm, leaving the production ingest humming right along.
> Additionally I'd like all ingest from vers. xx to go to a spare disk,
> not to the production disk.
> 
> If I set $NAWIPS and $GEMDATA for the vers. xx and the spare disk
> destination while building vers. xx, then run ldm/etc/gen_pqact.csh for
> some pqact files, substitute 'decoders' for 'path-to-vers.xx.gemexe',
> for example, then it seems like the resulting correct vers.xx of $GEMTBL
> in the pqact entries will put everything onto the spare disk.

Neil,

This isn't the case, because GEMDATA isn't used in the templates of
the pqact files. All of the paths are configured into the supplied
templates as relative to the ~ldm distribution as data/gempak/etc.
So, changing GEMDATA only affects where the application programs look 
for the data, but not the LDM's pqact files that are generated.

To run a separate set of pqact's, you will have to modify the
relative paths of the pqact.conf entries. Also, the dcgrib2
decoder will use the $GEMTBL/grid/gribkey.tbl file when a
file name is not provided, so the locations in that table (again are relative)
would have to be changed. Thios file could be changed easily with a global
search/replace (note that it is copied from 
$NAWIPS/unidata/ldmbridge/dcgrib2/gribkey.tbl
to $GEMTBL/grid/gribkey.tbl on install, so it will get overwritten it "make 
install"
is run again in the dcgrib2 directory.

Say you want to use ~ldm/data_spare/ as a symlink to your spare data disk.
Then "vi $GEMTBL/grid/gribkey.tbl" and type:
:%s/data/data_spare/g

Then save the file with
:wq

I have attached an alternate version of gen_pqact.csh called 
gen_pqact_GEMDATA.csh
where you can modify the RELATIVE_GEMDATA variable at the top of the file and 
it will 
change the data/gempak locations to that value. Place the output pqact files is
a sparate subdirectory under ~ldm/etc such as ~ldm/etc/GEMPAK_test/
so they don't get confused with your oerating versions, and create the exec 
lines in
ldmd.conf accordingly to reference the subdirectoru of the non-production 
pqact.conf files.

You can then define your experimental version GEMDATA in the Gemenviron file to
that data_spare disk location. 


Steve Chiswell
Unidata User Support




> 
> But I've seen so far in my experimentation that the ingested model data,
> for example from the pqact.gempak_decoders file generated as above, is
> writing to the $GEMDATA of the production Gempak vers. x destination
> disk, not the spare disk. If have included a sym link in ~ldm pointing
> to the spare disk; I've also tried adding the pqact option '-d
> symlink-to-sparedisk' in the 'exec' line for this pqact file in
> ldmd.conf. But things like the running ldm's values for $GEMDATA and
> $MODEL are difficult to control.
> 
> Where all do I need to look to make sure these experimental 'exec' lines
> and pqact.conf files are outputing to my desired non-production data
> disk using my non-production Gempak build? -- assume that I'd like to
> use the UPC's default directory structure and pqact entries, and not
> have to specify a destination specification for those entries in the UPC
> gen_pqact.csh -generated files that depend on $GEMTBL/config/datatype.tbl.
> 
> [ muddy enough? ]
> 
> -Neil
> 
> --
> Neil R. Smith, Comp. Sys. Mngr.               address@hidden
> Dept. Atmospheric Sci., Texas A&M Univ.       979/845-6272
> 
> 


Ticket Details
===================
Ticket ID: XTR-273547
Department: Support GEMPAK
Priority: Normal
Status: Closed

Attachment: gen_pqact_GEMDATA.csh
Description: Binary data