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)
- =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 forecast | deterministic forecast | |||
| Octets | perturbed (pf) | control (cf) | forecast * (fc) | |
| 21 | type of processed data | 4 | 3 | 2 |
(*) high-resolution forecast interpolated to ensemble resolution (new request from 2020 for TIGGE, phase III)
| Ensemble (section 4, template 4.61) | ||||
|---|---|---|---|---|
| ensemble forecast | deterministic forecast | |||
| Octets | perturbed (pf) | control (cf) | forecast * (fc) | |
| 8-9 | product definition template number | 1/11* | 1/11* | 0/8* |
| 35 | type of ensemble forecast | 3 | 1 | |
| 36 | perturbation number | <eps number> | 0 | |
| 37 | number 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,....)