MRG Interactive Developments

Grib-formatted binary files contain individually tagged (self-describing) records for each field present in the dataset (i.e. each variable, level and analysis time represents an individual record). The fields which describe the grid are, in general, the GDS and PDS sections. Each of these sections contains a series of octects which are used to efficiently pack the grid information into the self-describing record header. Using GEMPAK, it is possible to the full descriptions of the individual records using the GBDIAG macro of the nagrib program provided with the distribution. Of particular note in this description is the parameter byte (9) of the PDS octet. This number (between 1 and 255) identifies the field associated with the record and is (obviously) very important for decoding the data.

To translate the PDS byte 9 (pds.parameter) values from Grib to GEMPAK formatted files, it is necessary to map each integer parameter value (in the Grib file) to a character (length < 6 to be on the safe side) name for the GEMPAK file. This is accomplished through a series of lookup tables stored in the $GEMTBL/grid directory of your GEMPAK distribution. Each centre has their own decoding tables since each (of course;) uses different integer encoding values when creating their Grib files. As if that isn't enough, each centre may have multiple versions of their Grib encoders which produce different integer field names for different variables. For example, the Version 3 Grib Table 2 from NCEP are saved in GEMPAK as $GEMTBL/grid/ncepgrib3.tbl. Each record header is capable of directing the decoder to the correct lookup table, so your job it just to make sure that the table is present and up-to-date.

For more information on the parameter and unit decoding of NCEP grib tables, see Office Note 388 from NCEP. For ECMWF-generated data, a plethora of Grib Table 2's exist, and can be found in the ECMWF document index. You'll have to do some more looking (or asking) for non-standard Grib tables from other centres.

Once you have ensured that you have the correct tables, decoding is as easy as running the dcgrib2 program provided with recent GEMPAK distributions. On older versions of GEMPAK, or if you find ensemble extensions cluttering your variable names, you should use the older dcgrib program with the -z option to force stripping of the unwanted characters. Run either command with the -h option to find out more information about command line structures.

The problem directly addressed here is the decoding of ECMWF Reanalysis data using Version 128 of ECMWF Grib Table 2. This version of the ECMWF parameter and units table (ecmwfgrib128.tbl) in GEMPAK distributions up to at least v5.7.2.p2 is a direct copy of the NCEP naming table, Version 2. The mapping between the two tables seems very poor, so although this linking of the tables allows for decoding, parameter names and unit scalings will likely be inappropriate. Using the information provided by ECMWF regarding their Reanalysis Grib naming conventions, it is possible to construct an up-to-date Table 2 for the ECMWF reanalysis, which is available for download (you may have to hold down the SHIFT key before left-pressing the download to prevent your browser from opening the text file directly). Note that you should move the original table to a temporary file while installing the new one, just in case you need to revert (for some bizarre reason) later to the original. Be aware that your browser may not prompt you before overwriting the distribution ecmwfgrib128.tbl table.

Once the new table is in your $GEMTBL/grid directory, you should run either dcgrib -z (no ensemble extensions) or dcgrib2 to decode your data into GEMPAK format. Remember to run with the -h first if you need help in running the degribbing applications.

Questions or Comments? Contact our WebMaster.