implementation of grib2 a discussion

Deutscher Wetterdienst

Implementation of GRIB2

A Discussion

COSMO Working Group 6: Reference Version and Implementation

Working Group Coordinator: Ulrich Schättler

06.09.2010 COSMO General Meeting 2010 2

Contents

General Remarks about using Grib2

The Grib Library to use: grib_api

Problems for the COSMO-Model

Vertical Coordinate Parameters in Grib2

Problems with coding the Reference Atmosphere

Generating Processes

Coordinate usage within COSMO


General Remarks about using Grib2

At the last General Meeting in Offenbach, Davide proposed guidelines for a „setup of a minimum-impact Grib2 I/O in COSMO-Model“

He also stated, that a more native Grib2 approach could be desirable

This is problematic, because we still have to support Grib1

Problems with keeping two versions of Grib can be kept to a minimum, if the ECMWF grib_api is used, because it tries to hide the differences between Grib1 and Grib2 as much as possible

At DWD, the decision was taken last autumn, to use the grib_api as standard grib library in the future

Therefore, we are going to implement grib_api into INT2LM and the COSMO-Model


GRIB 1 vs. 2: Different StructureGRIB 1SECTION 0 Indicator (GRIB)

SECTION 1 Product definitionSECTION 2 Grid Description

SECTION 3 BitmapSECTION 4 Binary DataSECTION 5 End (7777)

GRIB 2SECTION 0 Indicator(GRIB,…)SECTION 1 IdentificationSECTION 2 Local UseSECTION 3 Grid DefinitionSECTION 4 Product DefinitionSECTION 5 Data RepresentationSECTION 6 BitmapSECTION 7 Binary DataSECTION 8 End (7777)

In GRIB 2 several variables are defined with more precision (e.g. angles are in micro-degrees, more vertical coordinates possible)

In GRIB 2 the description of the data (parameter, time, statistics,…) is more complex and is template/table based

Comparing Grib1 – Grib2


Element coding of model fields in GRIB2

GRIB1: Element coding by ee (element) and tab (table)

Example: temperature is ee=11 in tab=2 (WMO)

GRIB2: Element coding by a triplet

discipline

category

parameter

Example: temperature is (0,0,0)

06.09.2010 COSMO General Meeting 2010 6 6

ECMWF source code for de-/encoding of GRIB1 AND GRIB2 no internal knowledge of GRIB structure needed each element of a grib message has an alphanumeric name (key) that can be used

to access the information linked to it (value) key – value approach: shortName=T

typeOfLevel = hybridLayer

topLevel = 37

bottomLevel = 38 flexible – local definitions for each centre possible

(i.e. local definition tables shortName.def for edzw (GRIB1 and GRIB2),

local definition of GME icosahedral grid for GRIB1) Offers a set of tools to work on Grib files: grib_ls, grib_dump, grib_get, grib_set, etc.

The Grib Library to Use: grib_api


Problems for the COSMO-Model

Problems derive from the fact, that we added some features to the Grib1, which were not standard. These were

Coding the vertical coordinate

Coding the reference atmosphere


Coding the Vertical Coordinate We code all these parameters as „vertical coordinate parameters“

ivctype Type of vertical coordinate (100: new reference atmosphere):

1: Pressure based hybrid coordinate

2: Height based hybrid coordinate

3: Height based hybrid SLEVE coordinate

ke Number of vertical levels

p0sl, t0sl, dt0lp, vcflat,

Parameters for the (old) reference atmosphere

delta_t, h_scal,

bv_ref

Additional parameters for the (new) reference atmosphere

svc1, svc2, nfltvc

Parameters for the SLEVE coordinates

vcoord(1:ke) Vertical coordinate parameters


Coding the Vertical Coordinate But only the list of vertical coordinate parameters should be there

Moreover, Grib only knows about „pairs of vertical coordinate parameters“ in combination with the surface pressure:

pressure = ak + bk * surface pressure (typeOfLevel = 119) or

height = ak + bk * surface height (typeOfLevel = 118; new in Grib2)

After the discussion we had in the last months, we proposed a new vertical coordinate type: typeOfLevel = 150

Do not specify vertical coordinate parameters together with a 2D field

but directly specify a 3D field (as a Grib message) with the height of all grid points

The list of vertical coordinate parameters can be used to specify additional information about the vertical grid:

NLAY: number of vertical layers (Note: # levels = # layers + 1)

NGRID: version number of vertical grid


Coding the Vertical Coordinate But what to do with the parameters for the reference atmospheres?

These parameters do not belong to the vertical grid and they are only necessary to interpret the field „pressure deviation from reference pressure“ (because they are needed to compute the reference pressure)

Using typeOfLevel = 150, we could still code them in the list of vertical coordinate parameters, because this is more or less „local use“ then.

But it is not nice

Are there different possibilities? Section 2, for example?


Generating Processes

Grib1 has an entry in the PDS to identify the „generating process“. This entry is used at DWD not only to identify the application (or generating process) but also as database identifier.

Grib2 offers several entries:

generatingProcessIdentifier

backgroundGeneratingProcessIdentifier

typeOfGeneratingProcess; typeOfProcessedData

It would be desirable to have some means to identify the different COSMO applications: COSMO-EU, COSMO-7, COSMO-I7, etc.

But taking a key only for COSMO would limit the local usage

Products can be defined by checking the „originatingCentre“ plus some product identifying keys.


Common COSMO Usage of Grib2

There are some issues that should be coordinated within COSMO

Identifying the COSMO fields by the „short names“: PS, T, TOT_PREC

We should try to avoid a „local usage“ wherever possible


Thank you

very much

for your

attention

implementation of grib2 a discussion

Documents