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

Re: gribdump modifications

Clint,

Thanks for the code mods/ideas.  At this time nobody has requested that
type of service but that doesn't mean it will not be needed in the future. 
I put the code on file.

One comment, if you only want to capture headers of products not already
process in the pqact.conf, you can use  ^_ELSE_$ pattern    ie,

HRS     ^_ELSE_$    PIPE
        gribdump_new -b -o data/HDS_(\3:yyyy)(\3:mm)\3\4.log

After all your other HDS pqact entries.

Robb....


On Wed, 16 Feb 2000, Clint Rowe wrote:

> Robb,
> 
> I don't know if anyone else would find it useful, but I had a need
> to find out what GRIB products we were not saving/decoding.  I didn't
> want to save the entire GRIB product, since that could consume quite 
> a bit of disk space quickly.  So I hit upon the idea of using gribdump.
> It turned out to be easier than I expected, since gribdump already
> read from stdin if no filename was given.  All I had to do was put in 
> an option for an output filename and change the printf's to fprintf's.
> Even though I'm not a C programmer, the structure you have in gribdump 
> made both tasks easy.  The only tricky thing I had to do was to keep it 
> from writing the header before each message.
> 
> Here's the pqact.conf entry for capturing all GRIB headers into hourly
> logs:
> 
> HRS     ^(......) (....) ([0-3][0-9])([0-2][0-9])(.*)
>         PIPE    gribdump_new -b -o data/HDS_(\3:yyyy)(\3:mm)\3\4.log
> 
> It works okay, but there are two minor problems. First, I end up with a 
> bunch of gribdump_new processes hanging around (i.e., they don't seem to
> time out properly).  I haven't worried about this, as I'm running this as 
> the only action on a separate machine than are normal ingester, so I only 
> run it occasionally and for relatively short time periods.  Second, I end 
> up creating log files every hour, even though no GRIB products arrrive 
> since any HRS product will kick off the process but non-GRIB products are
> not processed by gribdump.  Again, this is a big problem since they're
> zero-length files.
> 
> I've attached the modified file.  Feel free to use it any way you want.
> 
> Clint
> 
> ====================================================================
> Clinton M. Rowe
> Associate Professor 
> Meteorology/Climatology Program                  phone:(402)472-1946
> Department of Geosciences                          fax:(402)472-4917
> University of Nebraska-Lincoln                        address@hidden
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================