Deutscher Wetterdienst Implementation of GRIB2 A Discussion COSMO Working Group 6: Reference Version and Implementation Working Group Coordinator: Ulrich Schättler

COSMO General Meeting 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

COSMO General Meeting 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

COSMO General Meeting GRIB 1 vs. 2: Different Structure GRIB 1 SECTION 0 Indicator (GRIB) SECTION 1 Product definition SECTION 2 Grid Description SECTION 3 Bitmap SECTION 4 Binary Data SECTION 5 End (7777) GRIB 2 SECTION 0 Indicator(GRIB,…) SECTION 1 Identification SECTION 2 Local Use SECTION 3 Grid Definition SECTION 4 Product Definition SECTION 5 Data Representation SECTION 6 Bitmap SECTION 7 Binary Data SECTION 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

COSMO General Meeting 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)

COSMO General Meeting  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

COSMO General Meeting 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

COSMO General Meeting 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

COSMO General Meeting 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 = a k + b k * surface pressure (typeOfLevel = 119) or  height = a k + b k * 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

COSMO General Meeting 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?

COSMO General Meeting 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.

COSMO General Meeting 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

COSMO General Meeting Thank you very much for your attention