The regional climate projections in the Climate Data Store (CDS) are a quality-controlled subset of the wider CORDEX data over Europe. These data represent only a small subset of CORDEX archive. A set of 30 core variables from the CORDEX archive were identified for the CDS. These are the most used of the CORDEX data. These variables are provided from 4 of the most popular CORDEX experiments that are derived from the CMIP5 experiments.
The CDS subset of CORDEX data have been through a metadata quality control procedure which ensures a high standard of reliability of the data. It may be for example that similar data can be found in the main CORDEX archive however these data come with no quality assurance and may have metadata errors or omissions. The quality-control process means that the CDS subset of CORDEX data is further reduced to exclude data that have metadata errors or inconsistencies. It is important to note that passing of the quality control should not be confused with validity: for example, it will be possible for a file to have fully compliant metadata but contain gross errors in the data that have not been noted. In other words, it means that the quality control is purely technical and does not contain any scientific evaluation (for instance consistency check).
In addition, CORDEX data for CDS includes Persistent IDentifiers in their metadata which allows CDS users to report any error during the scientific analysis. The error will be at least documented on the ESGF Errata Service (http://errata.es-doc.org) but also corrected with a new dataset version published on the CDS.
The CDS subset of CORDEX data are provided as NetCDF files. NetCDF (Network Common Data Form) is a file format that is freely available and commonly used in the climate modeling community.
NetCDF files are accessible by many programming languages such as Python, R, IDL, C, C++ and Fortran.
A NetCDF file contains:
The metadata provided in NetCDF files adhere to the Climate and Forecast (CF) conventions. The rules within the CF-conventions ensure consistency across data files, for example ensuring that the naming of variables is consistent and that the use of variable units is consistent.
The CDS subset of the CORDEX data have been through a set of quality control checks before being made available through the CDS. The objective of the quality control process is to ensure that all files in the CDS meet a minimum standard. Data files were required to pass all stages of the quality control process before being made available through the CDS. Data files that fail the quality control process are excluded from the CDS-CORDEX subset or if possible the error is corrected and a note made in the history attribute of the file. The quality control of the CDS CORDEX subset checks for metadata errors or inconsistencies against the Climate and Forecast (CF) Conventions and a set of CORDEX specific file naming and file global metadata conventions.
Various software tools have been used to check the metadata of the CDS CMIP5 data:
The data within the files were not individually checked.
It is important to note that passing of these quality control tests should not be confused with validity: for example, it will be possible for a file to be fully CF compliant and have fully compliant CMIP5 metadata but contain gross errors in the data that have not been noted.
The CDS-CORDEX subset consists of the European and Mediterrean CORDEX domains (aka EUROCORDEX and Med-CORDEX).
Further details on each domain (boundaries, projections, etc.) are available on the related links above.
The CDS-CORDEX subset consists of the following CORDEX experiments partly derived from the CMIP5 ones:
Further details can be found on the Earth System Documentation site.
Regional climate simulations needs boundary conditions related to the CMIP experiment of interest. Those boundary conditions impose changing conditions for the whole regional climat run. The CDS-CORDEX subset used boundary conditions are extracted from CMIP5 global projections. A set of boundary conditions can be extracted from a given experiment of a given driving GCM. Thus, CORDEX framework requires each RCM downscale a minimum of 3 GCMs for 2 scenarios (at least RCP8.5 and RCP2.6). The two scenarios more or less cover the full IPCC range. The number of 3 for the GCMs is a minimum, ideally 5-6 GCMs would be better, if feasible. The C3S-CORDEX subset aims to fill the gaps in this matrix between GCMs (aka "driving models) and RCMs.
The models included in the CDS-CORDEX subset are detailed in the table below, these include 12 of the models from the main CORDEX archive. However a small number of models were not included as the data from the models have a research-only restriction on their use, all data in the CDS are released without restriction.
The driving GCMs used to produced the CDS-CORDEX subset are details in the table below, these include 8 of the models from the main CMIP5 archive. However a small number of models were not included as the data from the models have a research-only restriction on their use, all data in the CDS are released without restriction.
| Driving Global Coupled Models | |||||||||||||||||||||||||
| HadGEM2-ES | EC-EARTH | CNRM-CM5 | NorESM1-M | MPI-ESM-LR | IPSL-CM5A-MR | CanESM2 | MIROC5 | ||||||||||||||||||
Regional Climate Models | RCA4 (SMHI) | 1 | 1 | 1 | 1 | 1 | 3 | 1 | 1 | 1 | 2 | 1 | 1 | 1 | 1 | 1 | |||||||||
| CCLM-8-17 (ETH) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| CCLM-GPU (ETH) | 1 | 3 | |||||||||||||||||||||||
| REMO 09&15 (GERICS) | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 3 | 1 | 1 | ||||||||||||||
| RACMO22E (KNMI) | 1 | 1 | 1 | 1 | 2 | 3 | 2 | 1 | |||||||||||||||||
| HIRHAM5 (DMI) | 2 | 1 | 1 | 3 | 1 | 1 | 1 | ||||||||||||||||||
| WRF361H | 1 | 1 | 1 | 1 | 1 | ||||||||||||||||||||
| WRF381P | 1 | 1 | 2 | ||||||||||||||||||||||
| ALADIN53 (CNRM) | 1 | 1 | 1 | ||||||||||||||||||||||
| ALADIN63 (CNRM) | 1 | 1 | |||||||||||||||||||||||
| RegCM4.6.1 (ICTP) | 1 | 1 | 1 | ||||||||||||||||||||||
| HadGEM3-RA (MOHC) | 1 | 1 | |||||||||||||||||||||||
| RCP26 | RCP45 | RCP85 | [0-9] = Number of simulations | ||||||||||||||||||||||
Each modelling centre will typically run the same experiment using the same model several times to confirm the robustness of results and inform sensitivity studies through the generation of statistical information. A model and its collection of runs is referred to as an ensemble. Within these ensembles, three different categories of sensitivity studies are done, and the resulting individual model runs are labelled by three integers indexing the experiments in each category.
Each member of an ensemble is identified by a triad of integers associated with the letters r, i and p which index the “realization”, “initialization” and “physics” variations respectively. For instance, the member "r1i1p1" and the member "r1i1p2" for the same model and experiment indicate that the corresponding simulations differ since the physical parameters of the model for the second member were changed relative to the first member.
It is very important to distinguish between variations in experiment specifications, which are globally coordinated across all the models contributing to CMIP5, and the variations which are adopted by each modelling team to assess the robustness of their own results. The “p” index refers to the latter, with the result that values have different meanings for different models, but in all cases these variations must be within the constraints imposed by the specifications of the experiment.
For the scenario experiments, the ensemble member identifier is preserved from the historical experiment providing the initial conditions, so RCP 4.5 ensemble member “r1i1p2” is a continuation of historical ensemble member “r1i1p2”.
On a general level in the CDS form for the RCM simulations “v” enumerates runs and NOT model versions. For the DMI, KNMI and SMHI runs numbers different from “v1” means new simulations relative to the first “v1” one. It might not mean a new version.
When you download a CORDEX file from the CDS it will have a naming convention that is as follows:
<variable>_<domain>_<driving-model>_<experiment>_<ensemble_member>_<rcm-model>_<rcm-run>_<time-frequency>_<temporal-range>.nc
Where