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

20010403: ECMWF data

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: 20010403: ECMWF data
  • Date: Tue, 3 Apr 2001 16:14:32 -0600

Greg,

The ECMWF sample GRIB data you sent me has some GRIBS using
second order packing. Not all use second order packing, so
you may see some grids where they don't appear as a constant value.
The constant value grids are a result of GEMPAK not providing
support for second order packing at this point.

I added support to $GEMPAK/source/gemlib/gb/gbgsec.c to decode
second order packing as defined in the WMO GRIB documentation,
however, ECMWF is apparently adding their own modifications to
the standard since they appear to be using ROW-BY-ROW packing
accoring  to the bit flags, but the bit widths do not agree,
nor do the sizes of expected regions.

If you have a contact at ECMWF, I can try to implement the ECMWF
modifications if I can get documentation on them. I have searched the
WEB for the past 3 days, but can't seem to find any code or documentation
that is matching the data values I am unpacking. I tried the generic
grib/gbytes routines at NCEP and NCAR, but they do the same thing I am
doing. The WMO grib documentation lists several bits as reserved. ECMWF
appears to be using some of these as well.

Steve Chiswell
Unidata User Support