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.
NOTE: The decoders
mailing list is no longer active. The list archives are made available for historical reasons.
Clint, Thanks for the code mods/ideas. At this time nobody has requested thattype 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'twant 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 alreadyread 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.logIt 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 arenot 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. RoweAssociate Professor Meteorology/Climatology Program phone:(402)472-1946Department of Geosciences fax:(402)472-4917 University of Nebraska-Lincoln crowe1@xxxxxxx
============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research rkambic@xxxxxxxxxxxxxxxx WWW: http://www.unidata.ucar.edu/ ==============================================================================
decoders
archives: