20040510: 20040506: Gemapk dcgrib cores

Adam,

The core dumps are definitely a problem and need to be resolved.
Possibly being caused by either not finding the correct tables, or
a corrupted grid file if your pqact is falling behind.
One way to check if pqact is falling behind is to issue 2
"kill -USR2 pid" commands where pid is the process ID of the pqact
in question. After issuing the kills, the pqact process will
be in debug mode. Looking at the ldmd.log file will
show "Delay" messages about the time between when the
product was received and when it was processed by
pqact. If this islarger than a few seconds, then
you probably have to split up your pqact processing
to multiple independent invocations in your ldmd.conf
file (for example the split pqact.gempak_xxxxx files
from the gen_pqact.cshscript in $NAWIPS/ldm/etc).

The messages about grid too large will occur with an icing
product from AWC which requires 1,679,940 points
where the default build has a maximum of 750,000, so that
is a correct log message.

A message of "bulletin too long" also signifies a correct behavior
by the decoder in detecting a product that is missing the end sequence 
in the proper location.

The messages about "no file template" and "table grib3.tbl not found"
both signify that the cntrgrib1.tbl and gribkey.tbl files in
$GEMTBL/grid are not correctly being found/read, or there
is garbage in the product they are decoding.
If your -e GEMTBL is correct, you may also need to verify that
the LDM has read access to the files.

Another problem could result if more than 1 decoder were writing to the
file at the same time, for example if things were running so slow that
pqact fired up a second PIPE because the first was full. That should
be evident in the logs by overlapping process ids.

Please provide your pqact.conf file, and your dcgrib.log file
for more information.

Steve Chiswell




>From: address@hidden
>Organization: UCAR/Unidata
>Keywords: 200405101526.i4AFQ0tK019287

>I have double checked everything three times.  All GEMTBL's are set for all 
>instances of dcgrib2 (everything else is working fine, even the call below 
>works most of the time).  The pqact call that is causing the cores is below:
>
>HDS|NMC2        ^([HOYZ]|/afs)
>        PIPE    decoders/dcgrib2 -v 1 -d logs/gempak/dcgrib.log
>        -e GEMTBL=/home/ldm/nawips/gempak/tables
>
>The couple of other instances of dcgrib2 that are being called, are for 
>FNEXRAD, NOGAPS, amd CMC.  These three have different log names like 
>dcgrib_fnmoc.log, dcgrib_cmc.log, and dcgrib_radar.log.  All of the core files
>  
>when you grep through the logs for the process id however all come from 
>dcgrib.log which is the log for HDS and NMC2.  So in a nut shell, i am still 
>getting core dumps from dcgrib2 and the same type of messages as listed in my 
>first email.  The only thing that has changed this weekend is that i saw that 
>there was version 5.7.2p2 out and i downloaded it, built it, and installed 
>it.  However i still get the same types of errors.
>
>I am really confused as to what is going on.
>
>Thanks
>
>Adam
>
>
>
>Quoting Unidata Support <address@hidden>:
>
>> 
>> Adam,
>> 
>> Sounds like your GEMTBL environmental variable is not set.
>> 
>> The pqact entres for dcgrib2 can be generated from
>> $NAWIPS/ldm/etc/gen_pqact.csh
>> (as described at the top of
>> 
>http://my.unidata.ucar.edu/content/software/gempak/GEMPAK5.7/configuration.htm
> l
>)
>> 
>> The gen_pqact.csh will use your GEMTBL environmental variable setting for
>> creating the pqact.conf entries. Your GEMTBL variable is set by sourcing 
>> $NAWIPS/Gemenviron.
>> 
>> The dcgrib2 entries use the -e GEMTBL=location setting for the decoder to
>> find the necessary tables to decoder grib. If this is not set, and
>> not in the environment of the LDM account that started the pqact process,
>> you will not get the proper tables.
>> 
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> 
>> 
>> >From: address@hidden
>> >Organization: UCAR/Unidata
>> >Keywords: 200405061848.i46ImJtK016553
>> 
>> >I have upgraded gempak to the newest version about a week ago 5.7.  Since
>> then
>> >  
>> >I have been getting alot of core files in the LDM directory.  greping
>> through 
>> >the logs has shown them all to be from the dcgrib2 decoder.  My dcgrib logs
>> 
>> >shows everything from "no file template", "Grid to large", "table grib3.tbl
>> 
>> >cannot be opened", "bulletin to long", and "Grid navigation 255 incompatibl
> e
>> 
>> >with file ....."
>> >
>> >HELP!!!!
>> >
>> >-- 
>> >Adam Taylor
>> >Computing Center
>> >University of Louisiana at Monroe
>> >
>> --
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ----------------------------------------------------------------------------
>> NOTE: All email exchanges with Unidata User Support are recorded in the
>> Unidata inquiry tracking system and then made publically available
>> through the web.  If you do not want to have your interactions made
>> available in this way, you must let us know in each email you send to us.
>> 
>
>
>-- 
>Adam Taylor
>Computing Center
>University of Louisiana at Monroe
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.