20010726: running GEMPAK5.6 decoders

James,

If your gempak was installed as a different user than
the LDM is running as:
It might be that your LDM account doesn't have file permission
to read in your GEMPAK 5.6 directory, in particular
the bin/sol directory, the $GEMTBL/stns files,
$GEMTBL/pack files and $GEMTBL/grid files. If necessary
do a "chmod -R a+r 5.6" if your umask setting
does not allow the LDM user to read the GEMPAK files.

Check your ~ldm/logs/ldmd.log file for any clues about
trying to fire up dcmetr or dcgrib2. Or the
$GEMDATA/logs files that they try to create.

You can run "ldd $GEMEXE/dcmetr" or "ldd $GEMEXE/dcgrib2"
to make sure that all the shareable libraries are being found.

Steve Chiswell






>From: James Murakami <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200107262206.f6QM6x124537

>Steve,
>
>Thanks to your tip in the last communique, I can now
>run gempak programs. It turned out that my .cshrc
>had a path to the old gempak bin directory. My "source
>Gemenviron" came somewhere after that, but I didn't 
>notice the earlier reference (a long gone programmer
>had set up my .cshrc).
>
>I'm almost completely there with the new GEMPAK package.
>My current problem is that the various decoders aren't
>running. A piece of the pqact.conf file follows (one example
>of surface and model data; tabs are included)--
>
># US and Canadian sfc obs and specials
>DDS|IDS        ^S[AP].* .... ([0-3][0-9])([0-2][0-9])
>       PIPE    /unidata/ldm/5.6/bin/sol/dcmetr -b 9 -m 72 -s sfmetar_sa.tbl
>       -d /data/logs/dchrly.log
>       -e GEMTBL=/unidata/ldm/5.6/gempak/tables
>       /gempak/data/surface/YYYYMMDD_sao.gem
>#
># NOAAport ETA grids
>HRS    ^[YZ].[QSRU].*/mETA
>       PIPE    /unidata/ldm/5.6/bin/sol/dcgrib2
>       -d /data/logs/dcgrib.log
>       -e GEMTBL=/unidata/ldm/5.6/gempak/tables
>
>I basically mimicked the decoders.tbl found on the unidata website.
>The paths are correct for our setup, but when I grep processes for
>ldm, I see ones for rpc.ldmd, pqact, and pqbinstats only. No process
>for dcmetr, dcgrib2, nor any other decoders start up. I see grid
>files and other data files feeding into the machine (using
>ldmadmin watch). I tried with a new product queue, but that didn't
>work either.
>
>So, for now, I'm still running the 5.4 decoders.
>
>I look forward to your advice on this matter. Thanks.
>
>James
>
>--------------------------------------
>James Murakami
>Staff Meteorologist/Student Affairs
>Department of Atmospheric Sciences
>University of California, Los Angeles
>405 Hilgard Ave.
>Los Angeles, CA  90095-1565
>
>
>   e-mail:  address@hidden
>telephone:  310-825-2418
>      Fax:  310-206-5219
>---------------------------------------
>
>
>> 
>> James,
>> 
>> does your LDM account automatically source the Gemenviron file?
>> 
>> If you already have $GEMEXE in you path, when you source Gemenviron,
>> it will tag the 5.6 path on at the end of you path so when you
>> type sfl604, you would be executing the 5.4 version with the 5.6 value of $G
> EMNTS.
>> 
>> 
>> Try typing "which sfl604". It should  be your /home/ldm/5.6/bin/sol/sfl604.
>> If it is still pointing to your 5.4 distribution, try setting PATH before
>> sourcing Gemenviron, like:
>> 
>> setenv PATH /usr/bin:/bin:.:/usr/local/bin:/usr/ucb
>> source Gemenviron
>> 
>> This will make sure that the 5.4 executables aren't in your
>> path when the 5.6 $GEMEXE is appended. The reason Gemenviron sticks the
>> $GEMEXE at the end of your path is so if you type "ps", you get the /usr/bin
> /ps
>> and not the Gempak postscript driver.
>> 
>> There was a change in the $GEMPDF and $GEMPARM file formats between 5.4 and 
> 5.6,
>> so the wrong executable will not be able to correctly process the help/setti
> ngs.
>> 
>> Let me know what you find.
>> 
>> Steve Chiswell
>> Unidata User Support
>