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

Re: 20010924: dcgrib2 problem: "bulletin too long"

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: Re: 20010924: dcgrib2 problem: "bulletin too long"
  • Date: Tue, 25 Sep 2001 05:54:39 -0600 (MDT)
Brian,

The number of grids decoded by dcgrib2 plus the ones flagged as incorrect equal
the same number of headers that griblook was outputting. So, that tells me that
dcgrib2 is finding the same pieces as griblook, but likely that griblook is not
checking the size against what is supposed to be there. Moreover, it is likely
that the extra unaccounted bytes are actually even more products that griblook
is not finding due to the missing 7777. 

The original "garble" check is based on receiving data from a satellite feed or
tty where you can't go back and put unneeded bytes back into the airwaves.
But it is still valid for files. It is possible that the file is corrupted by
multiple process writing to the file, or you ftp'd the file as it was being
written to/overwritten. If the same file ftp'd at 2 different times has the same
errors, then it is not likely the latter. The best way to see what is happening
is to split out all the individual messages in the file into separate files
and look at the structure of the messages that are not correct.

Steve Chiswell
Unidata User Support


On Mon, 24 Sep 2001, Brian Jewett wrote:

> Steve,
> 
> Thank you for your quick reply.  We had assumed we were missing grids
> due to I/O problems over our data feed.  However, the problems I
> reported were with 211 grids ftp'd from the OSO server at NCEP.
> I'm assuming the data are actually ok.
> 
> In addition, when dcgrib2 was done, some of the fields 'missing' from
> the resulting gempak file were ones which the "griblook" utility
> reported were present in the original GRIB data file.  Perhaps that
> program did not check as thoroughly - and was reporting header
> contents rather than the data structures which follow.
> 
> It seems unlikely that the files pulled off NCEP were garbled -
> have you heard of such an occurrence?  Could we have a configuration
> problem on our end which would produce this result?
> 
>   Brian
> ----------------------------------------------------------------------------
> Dr. Brian F. Jewett
> Dept. of Atmospheric Sciences & NCSA, University of Illinois
> 216 Atmospheric Sciences   (217-333-3957)      email: address@hidden
> 5249 Beckman Institute     (217-244-1998)
> FAX: (217) 244-4393                    http://uiatma.atmos.uiuc.edu/~jewett/
> ----------------------------------------------------------------------------
> 
>