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.
Greg, Use dcgrib2, which can handle the large grids. Edit $NAWIPS/unidata/ldmbridge/dcgrib2/decode_grib.c and change the maxgrib size to 1,000,000 bytes: #define MAXGRIBSIZE 1000000 rebuild with: cd $NAWIPS/unidata/ldmbridge/dcgrib2/ make clean make all make install make clean You will need to come up with an ecmwfgrib128.tbl file (as well as wmogrib128.tbl file). I did a quick run through and found that most of the products were in the 128-255 id range which means that you need the ecmwfgrib128.tbl for identifying these parameter ids. After creating some bogus tables, I was able to decode. Steve Chiswell Unidata User Support On Tue, 13 Mar 2001, Greg Stossmeister wrote: > Steve, > I got a sample of the uncompressed grib files today and had trouble > reading them with dcgrib. I got the following error message: > > Mar 13 22:23:06 dcgrib[24481]: oversize GRIB product 2 > Mar 13 22:23:06 dcgrib[24481]: oversize GRIB product 2 > Mar 13 22:23:06 dcgrib[24481]: oversize GRIB product 2 > Mar 13 22:23:07 dcgrib[24481]: oversize GRIB product 2 > Mar 13 22:23:07 dcgrib[24481]: oversize GRIB product 2 > Mar 13 22:23:08 dcgrib[24481]: error reading GRIB product > > I've put a sample file on our anonymous ftp site if you want to look > I'll ask for a sample compressed file tomorrow. > > Thanks, > Greg > > > Steve Chiswell wrote: > > > > Greg, > > > > I haven't heard of this 120 byte padding. The only byte filling I know of > > is in the BDS where the octets are filled with zeros to an even number. > > If they are changing the BDS or something else, then I would need to > > see the grib spec. > > > > I would ask for an example of their data and we can determine if it can be > > decoded. Nothing in the code that I have expects boundaries at a specific > > padded point- so may be this is something that they use internally to > > make boundary identification easier. Since we don't use anything like > > that, it wouldn't be a problem if it didn't exist. > > > > Steve > > > > On Tue, 13 Mar 2001, Greg Stossmeister wrote: > > > > > Steve, > > > We about to start receiving ECMWF grid data for the ACE_Asia project. > > > They (ECMWF) are asking if we can deal with a the second-order packing > > > scheme of the GRIB data. Can you tell me, can GEMPAK handle this: > > > > > > >All data will be disseminated in the WMO GRIB Code. There is one > > > >dissemination file per analysis or forecast timestep. All files are > > > >pure binary Unix files and all GRIB messages are rounded to a multiple > > > >of 120 bytes. The order of GRIB fields within the files is not > > > >guaranteed. No type of UNIX compression is used but an option for > > > >grid point data is to use the second-order packing feature of GRIB and > > > >to remove the 120 byte padding. This is recommended as it makes the > > > >files significantly (40%) smaller. > > > > > > Secondly Steve, if GEMPAK can handle this, does it do so > > > transparently, or do I have to do something different? > > > > > > Thanks, > > > Greg > > > > > -- > _____________________________________________________________________ > Greg Stossmeister "Every generation of Americans needs to > UCAR / Joint Office know that freedom consists not in doing > for Science Support what we like, but in having the right to > Voice: (303) 497-8692 do what we ought" - Pope John Paul II > Fax: (303) 497-8158 > e-mail: address@hidden JOSS Home Page: www.joss.ucar.edu > _____________________________________________________________________ >