Introduction

A parameter in GRIB1 is specified in the WMO code table 2 by the two keys, table version and indicator of parameter.

GRIB2 uses instead the three keys: discipline, parameter category and parameter number. This sub-divides the parameter list in disciplines like for example Meteorology or Oceanography, which are then further divided into different parameter categories like moisture or momentum.

A parameter in GRIB1 is in principle fully described by the two keys.

In GRIB2 an orthogonal structure of the parameter description is used. GRIB2 parameters are defined by WMO as basic parameters, meaning that there is for example no statistical process or level specified. This specification is then provided by defining additional keys.

Maximum temperature example

An example is the Maximum temperature, which has a specific entry in the WMO GRIB1 code table, whereas in GRIB2 the basic parameter Temperature should be used, extended by the key typeOfStatisticalProcessing=2, which specifies that it is the maximum. In GRIB2, this can be even further specified by adding for example the length of the time window over which the statistical processing was performed.

The WMO codings for GRIB2 parameters are listed in WMO code table 4.2. 

At ECMWF, so-called concepts are used in ecCodes to hide the technical details and to facilitate the usage of GRIB. The concepts contain a set of GRIB keys and define for this specific set among others the high-level edition independent keys paramId, shortName, name and units. They are defined in the parameter database and in the ecCodes definitions. The concepts are defined for the parameters defined in the WMO tables as well as in centre specific versions for example to define parameters with units different to those published by the WMO.
Here's an example of the name concept for the Maximum temperature in GRIB1 and GRIB2:

GRIB1 name concept: 'Maximum temperature' = {tables2version = 3, indicatorOfParameter = 15}
GRIB2 name concept: 'Maximum temperature' = {discipline = 0, parameterCategory = 0, parameterNumber = 0, typeOfStatisticalProcessing = 2}

The following example shows how the WMO and ECMWF paramId concepts in your ecCodes installation look like:

# replace paramId.def with shortName.def, name.def or units.def to see the other concepts

# show paramId concepts for WMO parameters
cat $(codes_info -d)/grib2/paramId.def
# show paramId concepts for ECMWF local parameter definitions
cat $(codes_info -d)/grib2/localConcepts/ecmf/paramId.def

$ codes_export_resource -d grib2/paramId.def paramId.def
$ cat paramId.def

ecCodes reads the concepts from ASCII files. If a certain paramId or shortName is requested within the ecCodes API or by the ecCodes binaries, the software compares the keys in the message with the keys in the concepts. For the mapping it is necessary that for each parameter, which is produced by one of the ECMWF models, a valid set of keys is defined. As it is not possible to map all parameters to the WMO tables, the missing parameters were/are proposed to be added to the WMO tables. Some of the parameters cannot be represented by simply adding code table entries.
For example, for the Extreme-Forecast-Index (EFI) parameters, templates have been proposed to allow the reference period used to calculate the M-climate to be encoded.