To simplify the usage of the GRIB 2 format within the COSMO Consortium, a COSMO GRIB 2 Policy has been defined. One element of this policy is to define a unified ecCodes system for the COSMO community, which is compatible with all COSMO software. This unified system is split into two parts, the vendor distribution of the ecCodes, available from ECMWF and the modified samples and definitions used by the COSMO consortium, available in the current repository.
Besides this document, more technical documentation is available in ./documentation/README.
The data in this repository must be used in conjunction with the correct version of the vendor distribution of the ecCodes, as specified by the RELEASE file (see next section).
The value of GRIB_DEFINITION_PATH in the host program must be set to "./eccodes-cosmo-resources/definitions:./eccodes-vendor/definitions" (or similarly). All required GRIB sample files are available in the directory "./eccodes-cosmo-resources/samples".
Compatibility of the release number with the host program should be checked, if possible at run time.
The release number takes the form vX.Y.Z.R, where vX.Y.Z is the version number of the associated vendor distribution of the libgrib-api, and Z an integer which is incremented each time some definition or sample is changed, and which is reset to 1 each time a new version of the vendor library is introduced. A release with a trailing 'd' signals development status; the release information identifies the target release.
All production releases are tagged, the tag value being the same as the version number.
Any changes to this repository, including the use of a different version of eccodes-vendor, must be validated with the COSMO technical test suite. In particular, the programs INT2LM, COSMO, and fieldextra must pass their respective regression suite, for all originating centers in {78, 215, 250}.
The master repository is COSMO-ORG/eccodes-cosmo-resources.
The master repository holds two main branches with an infinite lifetime. The master branch only contains data in a production-ready state which has been fully tested; all commits on the master branch are tagged. The develop branch is used to collect new features for the next release.