This page contains a rules on the TIGGE data encoding. A complete list of all parameters and sample GRIB2 encoding is given here.

General

Units

  • All fields should use units as defined in GRIB Edition 2

Accumulations

  • All accumulations should start from the step 0
  • The step 0 must be a part of all forecasts, all members, etc
  • The values of accumulated fields must be set to zero for t=0

Fluxes

  • The flux sign convention will be positive downwards.

Missing values

Bitmaps should be used to indicate missing values (i.e. Soil moisture (sm) must be coded using a bitmap, because there is no model output over the sea)

Grid and resolution

Each partner will provide their eps data on the grid of their choice, although regular grids are favoured. Partners are encouraged to provide also their deterministic forecast (as additional control) projected on the same horizontal grid and resolution as the ensemble members.

Grids are defined in GRIB2 using an accuracy of 1/1000000 (one millionth) of a degree. If this accuracy is not sufficient to describe your grid (latitude/longitude of first and last points, as well as grid increments) without loss of information, you can use a GRIB2 feature that provides a way to describe any regular grid. See the page on encoding global latitude/longitude grid for more details.

Number of forecasts

  • The Control Forecast must be number 0,
  • The number of members is identical to the number of all EPS members plus the Control Forecast.

GRIB encoding

TIGGE GRIB2 checking tool

The so called tigge_check tool is a part of ecCodes package. It should be used to validate all GRIB2 files prepared for TIGGE. The tool is checking all encoding details so that only fully compliant TIGGE files following exactly required definitions would pass. Find more information about the tool in the page Data encoding checking tools

Encoding

General GRIB2 key

  • gribMasterTablesVersionNumber ie.g <=4
    • =17 (current latest one released in 2019)
  • localTablesVersion=0
    • no local tables should be used

TIGGE Production status of processed data

Octet 20 of section 1 of a GRIB2 message contains the Production status of processed data. The WMO has added two values to table 1.3 Production status of data:

  • 4:TIGGE operational products
  • 5: TIGGE test products

Ensemble and deterministic forecasts

Control and perturbed forecasts are identified in section 1 and 4. The following tables explains how to code them in GRIB2:

Section 1


ensemble forecastdeterministic forecast
Octets
perturbed (pf)control (cf)forecast * (fc)
21type of processed data4 3 2

(*) high-resolution forecast interpolated to ensemble resolution (new request from 2020 for TIGGE, phase III)


Ensemble (section 4, template 4.61)


ensemble forecastdeterministic forecast
Octets
perturbed (pf)control (cf)forecast * (fc)
8-9product definition template number

1/11* 

1/11*

0/8*
35type of ensemble forecast31
36perturbation number<eps number>0
37number of forecasts in ensemble<eps size><eps size>
  • statistically processed (typeOfStatisticalProcessing is set up)

Sample data

Data exchange

The input fields should be split by the output data type, level type and eps number as per below. All steps  should be merged into the same file.

Naming convention

tigge_CCCC_YYYYMMDDHH_VVVV_TT_LL_NNN.grib2   ... for ensemble  forecasts

tigge_CCCC_YYYYMMDDHH_VVVV_TT_LL.grib2   ... for high resolution forecasts

  • CCC: centre acronym  (e.g. kwbc for NCEP data)
  • YYYYMMDDHH: date * time stamp (e.g. 2019100100 for 0Z run on 2019-10-01)
  • VVVV: test/prod
  • TT: cf/pf/fc (output type i.e. control forecast/eps member/high resolution forecast)
  • LL: pl/sl/pt/pv (level type i.e. pressure/surface/pv level/pt)
  • NNN: eps number (cf=000, eps1=001,....)