Replies: 7 comments
-
I wonder how the values of scaleFactorOfFirstFixedSurface/scaledValueOfFirstFixedSurface and scaleFactorOfSecondFixedSurface/scaledValueOfSecondFixedSurface are translated within the typeOfLevel concept. This is for instance interesting, when a vertical integration between two surfaces with typeOfFirstFixedSurface = typeOfSecondFixedSurface=150 is performed. When I performed tests for IDPI, I noticed that the information on one of the two surfaces was lost. Maybe example of integrating between two surfaces of level type 150 is in practice irrelevant, but we have an example product, which includes the integral mean of potential vorticity in a layer defined by two isobaric surfaces. |
Beta Was this translation helpful? Give feedback.
-
Note that currently definitions/grib2/localConcepts/lssw points to definitions/grib2/localConcepts/edzw, i.e., we follow the COSMO GRIB2 policy here. |
Beta Was this translation helpful? Give feedback.
-
"All attributes that are named like GRIB_ are keys decoded from grib": |
Beta Was this translation helpful? Give feedback.
-
"Historically Fieldextra kept a dictionary with all variables, mapping the name to the combination of parameter keys that represent in grib that variable": The mapping between short name and the tuple of GRIB2 keys that is defining a parameter is / or should be the same as in eccodes-cosmo-resources/definitions/grib2/localConcepts//shortName.def. The unit and the name of the parameter are the same as in eccodes-cosmo-resources/definitions/grib2/localConcepts//name.def and eccodes-cosmo-resources/definitions/grib2/localConcepts//units.def, respectively. |
Beta Was this translation helpful? Give feedback.
-
Thanks @petrabaumann, |
Beta Was this translation helpful? Give feedback.
-
Proposal for conditional loading of grib keys here: |
Beta Was this translation helpful? Give feedback.
-
Resolution and component Flags is here: |
Beta Was this translation helpful? Give feedback.
-
cfgrib.open_datasets produces xarray datasets that follow the CF data model and conventions. They look like:
where the Dataarrays look like:
All attributes that are named like GRIB_ are keys decoded from grib.
Any DataArray or Dataset that follows this data model can in principle be written into a grib file by calling canonical_dataset_to_grib
https://github.com/ecmwf/cfgrib/blob/8578f1012974e88d962f3fa13c0fcca973e49114/cfgrib/xarray_to_grib.py#L255
However there are few important remarks that define the behaviour of the functionality that writes grib records.
In the parameter namespace, writing a variable require knowing the triplet discipline, parameterCategory and parameterNumber. For some variables additional keys need to be specified.
Historically Fieldextra kept a dictionary with all variables, mapping the name to the combination of parameter keys that represent in grib that variable:
https://github.com/COSMO-ORG/fieldextra/blob/74641a1edf563c5478accbdf003d3aad94010ba1/resources/dictionary_cosmo.txt#L216
Following that approach would require maintaining a similar dictionary (in yaml) for iconarray.
The approach of eccodes is though different. They implement the mappings of the various required parameter keys into a unique identifier (paramId) in the local concepts.
https://github.com/ecmwf/eccodes/blob/develop/definitions/grib2/localConcepts/edzw/paramId.def
Each center can have its own concept.
The function cfgrib.canonical_dataset_to_grib will then require an attribute GRIB_paramId and use the local concepts to define the various parameter grib keys in the record. In order for that to work, GRIB_centre must be set appropriately.
Similarly, for specifying the vertical coordinates, various keys are often required. While Fieldextra encodes those in the same dictionary, eccodes uses another concept (typeOfLevel):
https://github.com/ecmwf/eccodes/blob/develop/definitions/grib2/typeOfLevelConcept.def
And cfgrib will then use the key GRIB_typeOfLevel to determine the combination of keys.
The proposal for iconarray is to look at those concepts in eccodes, and make sure that they mimic the same behaviour fieldextra does for COSMO/ICON data. If there would be differences in behaviour we should fix them in the concept for our centre lssw
Beta Was this translation helpful? Give feedback.
All reactions