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

[CONDUIT #SCC-464262]: CONDUIT GRIBs

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [CONDUIT #SCC-464262]: CONDUIT GRIBs
  • Date: Wed, 24 May 2006 10:37:31 -0600
> Hi,
> I know I have talked about this before, but in the CONDUIT grids, is it
> possible to have "GRIBGRIB" in the feed.
> So, I have a sequence of characters at the end a GRIB message and the
> beginning of the next one as 7777GRIBGRIB
> Since GRIB messages are between GRIB and 7777, this is causing problems
> in some of our decoding.
> Thanks!
> Kevin Baggett
> UW-SSEC
> 
> 

Kevin,

It would be possible to have the string GRIB within a product, but in general,
the beginning of the GRIB product should start with GRIB followed by the IDS 
block,
so you should not see GRIBGRIB at the beginning of a product. Any sequence
of 7777GRIBGRIB could theoretically occur within the GRIB as random characters.

The program which finds the GRIB products from within the NWS ftp server files
is already doing a QC on the GRIB...size...7777 for each product, and is
reporting the sum of bytes inserted into the LDM queue as compared to the
NWS ftp server file being inserted in the .status file in the data stream. 
The only time these differ would be if a duplicate product were encountered.
Only valid grib products within the NWS file will be able to be placed into the 
LDM queue.

I store each individual GRIB product from the GFS003 stream at:
http://motherlode.ucar.edu/cgi-bin/ldm/conduit_reception.csh
If you have a time and or product in question, we can look at the complete 
product.
I grepped for "GRIBGRIB" for the 12Z GFS today, and didn't find any occurences.

A possible problem is that your output from pqact is stepping on itself. Have 
you verified that you 
don't have 2 XCD occurences? If the pqact process piping data out to XCD fills 
up, then you could
be generating a second instance of the pipe which I'm assuming is writing to 
your curcular buffer. 
That would explain why a different installation you have does not have problems 
if the load, hardware, 
or other variables differ.

Steve Chiswell
Unidata User Support

Ticket Details
===================
Ticket ID: SCC-464262
Department: Support CONDUIT
Priority: Normal
Status: Closed