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

Re: [Fwd: ECMWF Grids for ACE-Asia]

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
> _____________________________________________________________________
>