[no subject]

Hello,

Geff has sent an email or two to you in the last day regarding a crippling
problem we are having with our gempak files.  I just want to provide more
details than he could on what is happening.  

Our surface, upperair and some model files are ending
up with "bad" data in them which causes gempak programs to do core dumps
and abort.  It is hard to find systematic failures in each day, but I have
noticed that the 00z surface data, for instance, always seems to be bad.  
I'm not sure if the following
clue helps, but when I tried SFLIST one day (the 16th), and had DATTIM=00,
it gave me only one observation (even with AREA=IA), with the YYMMDD/HHMM 
listing
being 000517/0000.  The file itself was 000516_sao.gem.  For DATTIM=000516/00,
it says the time is not found in the data set.

Otherwise, the problem seems most common (in the surface data) in the first 
12 hours of each day,
but it doesn't always include the same hour.  For instance, 9z is fine today,
but failed the previous few days.  In the 000518_sao.gem file, the observation
from KADU is one that has the problem.  If AREA=@ADU, core dumps occur for
several hours (like 00z or 09z).

The problem is also affecting our model data files.  In these files, some
fields are fine, but others cause GDCNTR or GDPLOT to abort with a core dump.
For instance in the 00z Eta from 000519, the GDAT=f12 500 mb HGHT forecast
caused a core dump.  The 24 hr forecast worked fine.

Sometimes before the abort/core dump, an error message.... [FL 168] appears.

We had occasionally had similar problems in the past (I believe after we 
switched
to a linux box for ingestion), and it seemed the problems disappeared if Geff
created an "old" subdirectory within our data directories, and simply moved
all the existing files into the /old subdirectory.  I'm not sure how/why that
helped (at best it was a crude band-aid), but this time around, it didn't
seem to help.   

The problem is quite serious - almost all of our gempak data this week is
unuseable, and unfortunately we use it for some nationally-used web-based
teaching tools.  The problem this week seemed to kick in within a few days
after we had our CONDUIT stream going (although I believe I was seeing this
same core dump in those files from the start).  Our CONDUIT data stopped
for some reason over last weekend, but then started up again on Monday.  
Although
it may have been a coincidence, the problem in our normal gempak datastream
seemed to start during that period when the CONDUIT data had ceased.  Geff
turned off the CONDUIT data yesterday, but the problem continued since then.
He did not move existing data into an "old" directory at that time yesterday,
however, so I suppose it is possible the old "band-aid" fix might work now
if we tried it, but that doesn't explain why the problem happens.

Bill
**********************************************
*  Bill Gallus                               *
*  Asst. Prof. of Meteorology                *
*  Dept. of Geological and Atmospheric Sci.  *
*  3025 Agronomy Hall                        *
*  Iowa State University                     *
*  Ames, IA 50011                            *
*  (phone) 515-294-2270                      *
*  (fax)   515-294-2619                      *
**********************************************