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

20010726: 20010726: running GEMPAK5.6 decoders

James, from your message below, your gempak logs should be in
/data/logs/dchrly.log and /data/logs/dcgrib.log.
Make sure the /data/logs directory exists, since GEMPAK won't create 
the log directory.

Dcmetr entry you have is decoding into /gempak/data/surface. Again, make sure 
that
directory exist. Dcmetr won't create the data directory either.

Dcgrib2 uses the $GEMTBL/grid/gribkey.tbl file to define the data directory
used for each type of grid data it finds. The table as I provide it 
is set to decode under the ~ldm/data/gempak/model/ directory (eg,
the paths in gribkey.tbll are data/gempak/model...relative to the running
LDM. To display this data in nmap, make sure the MODEL environmental variable
is correctly defined in Gemenviron.

You will have to modify those paths acccordingly to your system. Dcgrib2 will
create directory paths as it needs.

Steve Chiswell
Unidata User SUpport



>From: James Murakami <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200107262313.f6QNDa127257

>Steve,
>
>The new version of gempak was installed and compiled on the ldm
>account. All the directories show read permissions.
>
>"ldd $GEMEXE/dcmetr" and "ldd $GEMEXE/dcgrib2" checked out
>fine. For example,
>
>/home/ldm> ldd $GEMEXE/dcgrib2
>        libm.so.1 =>     /opt/SUNWspro/lib/libm.so.1
>        libsocket.so.1 =>        /usr/lib/libsocket.so.1
>        libnsl.so.1 =>   /usr/lib/libnsl.so.1
>        libF77.so.4 =>   /opt/SUNWspro/lib/libF77.so.4
>        libM77.so.2 =>   /opt/SUNWspro/lib/libM77.so.2
>        libsunmath.so.1 =>       /opt/SUNWspro/lib/libsunmath.so.1
>        libc.so.1 =>     /usr/lib/libc.so.1
>        libdl.so.1 =>    /usr/lib/libdl.so.1
>        libmp.so.2 =>    /usr/lib/libmp.so.2
>
>Funny that you mention "ldmd.log". None had been created for
>a week now. I think I accidentaly erased them last week when
>I was cleaning up various directories (so that I could compile
>the new gempak). How can I start that process up again?
>
>Do you have any other suspect areas to check?
>
>James
>
>
>> 
>> 
>> 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/sfl60
> 4.
>> >> 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 a
> nd 
>> > 5.6,
>> >> so the wrong executable will not be able to correctly process the help/se
> tti
>> > ngs.
>> >> 
>> >> Let me know what you find.
>> >> 
>> >> Steve Chiswell
>> >> Unidata User Support
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>