In October 2018, the European Flood Awareness System (EFAS) started archiving its operational hydrological model output in the Meteorological Archival and Retrieval System (MARS) hosted by ECMWF. This marked the end of a long project to define new templates and data models for storing post-processed data in MARS in the GRIB2 format. The new capabilities in MARS have made the archiving of EFAS data more robust and more flexible for product generation purposes. They have also opened up MARS for storing data from any downstream application based on numerical weather prediction (NWP) output. ECMWF is the computational centre for EFAS, a flood forecasting system which is part of the EU-funded Copernicus Emergency Management Service (CEMS) (see diagram).
Requirements
Users often request output from EFAS. That is why a few years ago ECMWF decided to make EFAS output available through MARS. This would enable a more structured delivery of data and improve internal workflows for the validation of operational forecasts and experiments. However, it soon became evident that there were a number of obstacles to overcome. First, very few hydrological variables had GRIB code definitions. New parameters were proposed to the World Meteorological Organization (WMO) and were accepted after some revision. Second, there was no ready-made template for a hydro-meteorological forecast chain where the hydrological model is forced with NWP output. For our purposes, we had to define a new template where important metadata from the NWP fields used is stored in the GRIB header of the hydrological output.
Implementation
Using EFAS as an example, the implementation of the new GRIB template enables the storage of information on the forcing data through the key ‘Input originating centre’. This should be the official code of the centre producing the NWP forcing data. For a multi-model system such as EFAS, this functionality is essential. The type of post-processing applied is stored in the key ‘Type of post-processing’. This refers to a local table storing information on the models used in the post-processing. In our example, the model used is the hydrological model LISFLOOD. The third key, ‘Input process identifier’, is used to store information on the model version used, which can be a combined identifier based on the model versions used to produce the forcing and post-processed data, or just the version of the post-processing model. There are four versions of the template to account for deterministic and ensemble forecasts as well as instantaneous and statistically processed values.
Benefits and future work
The data model for post-processed data was deliberately made generic to account for different types of applications using NWP output, including calibrated forecasts, impact models and verification. The template has so far been implemented for EFAS operational forecasts and the EFAS climatology. Seasonal and sub-seasonal hydrological forecasts, including hindcasts, are expected to be added soon. Other downstream applications, such as the Global Flood Awareness System (GloFAS) and the fire forecasting output from the European Forest Fire Information System (EFFIS), will follow suit. EFAS data is currently archived under the new class ‘Copernicus Emergency Management Service (CEMS)’ in MARS. One of the immediate benefits of this implementation is that it can facilitate the delivery of non-restricted EFAS data through the Copernicus Climate Data Store for public access.