Implementation of GRIB2 A Discussion

1. Implementation of GRIB2A Discussion COSMO Working Group 6: Reference Version and Implementation Working Group Coordinator: Ulrich Schättler

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

3. 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 General Remarks about using Grib2 COSMO General Meeting 2010

4. Comparing Grib1 – Grib2 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 COSMO General Meeting 2010

5. 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) Element coding of model fields in GRIB2 COSMO General Meeting 2010

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

7. 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 Problems for the COSMO-Model COSMO General Meeting 2010

8. We code all these parameters as „vertical coordinate parameters“ Coding the Vertical Coordinate COSMO General Meeting 2010

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

10. 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? Coding the Vertical Coordinate COSMO General Meeting 2010

11. 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. Generating Processes COSMO General Meeting 2010

12. 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 Common COSMO Usage of Grib2 COSMO General Meeting 2010

13. Thank you very much for your attention COSMO General Meeting 2010