NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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 >