Regional climate projections in the CDS

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.

Data Format

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: 

• Global metadata: these fields can describe many different aspects of the file such as
• when the file was created
• the name of the institution and model used to generate the file
• links to peer-reviewed papers and technical documentation describing the climate model,
• the persistent identifier used to track the file annotations,
• and when, and  links to supporting documentation on the climate model used to generate the file or 
• software used in post-processing. 
• variable dimensions: such as time, latitude, longitude and height
• variable data: the gridded data
• variable metadata: e.g. the variable units, averaging period (if relevant) and additional descriptive data

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.

Quality control of the CDS-CORDEX subset

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 Quality Assurance compliance checking tool from DKRZ is used to check that: 
• the file name adheres to the CORDEX file naming convention, 
• the global attributes of the NetCDF file are consistent with filename,
• there are no omissions of required CORDEX metadata.

• The CF-Checker Climate and Forecast (CF) conventions checker (included in the QA-DKRZ) ensures that any metadata that is provided is consistent with the CF conventions. 

• When possible (i.e., optional),  the Time Axis checker developed by the IPSL is used to check the temporal dimension of the data:
• for individual files the time dimension of the data is checked to ensure it is valid and is consistent with the temporal information in the filename, 
• where more than one file is required to generate a time-series of data, the files have been checked to ensure there are no temporal gaps or overlaps between the files.

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.

Domains

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.

Experiments

The CDS-CORDEX subset consists of the following CORDEX experiments partly derived from the CMIP5 ones:

• evaluation: Models must carry out simulations with imposed changing condition following ERA-Interim reanalyses (1979-2015).

• historical: Models impose changing conditions (consistent with observations from 1850-2005), which may include: atmospheric composition due to both anthropogenic and volcanic influences, solar forcing, emissions or concentrations of short-lived species and natural and anthropogenic aerosols or their precursors, as well as land use.

• piControl (Pre-industrial Control): Models impose non-evolving, pre-industrial conditions, which may include prescribed atmospheric concentrations or non-evolving emissions of gases, aerosols or their precursors, as well as unperturbed land use.
• The piControl experiment is often run for a long number of years (500 or more) this allows for the models to reach an equilibrium state however this means that model data from this experiment only have a time element where the year is a modeling year not a representative year. Therefore to avoid confusion this experimental data is currently only available through the CDS API and will not be visible through the data download menu.

• Scenario experiments RCP2.6, RCP4.5, RCP6.0, RCP8.5: Future projections (2006-2100) forced by RCP2.6, 4.5, 6.0, and 8.5. RCPs (representative concentration pathways) approximately result in radiative forcings of 2.6, 4.5, 6.0 and 8.5 W m-2 at the year 2100 respectively, relative to pre-industrial conditions.

Further details can be found on the Earth System Documentation site. 

GCM vs. RCM matrix

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.

Regional Models 

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.

Driving Global Models

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.

Ensembles

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. 

• The first category, labelled “realization”, performs experiments which differ only in random perturbations of the initial conditions of the experiment. Comparing different realizations allow estimation of the internal variability of the model climate. 
• The second category refers to variation in initialisation parameters. Comparing differently initialised output provides an estimate of how sensitive the model is to initial conditions. 
• The third category, labelled “physics”, refers to variations in the way in which sub-grid scale processes are represented. Comparing different simulations in this category provides an estimate of the structural uncertainty associated with choices in the model design. 

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.

• DMI

1. For the EC-EARTH r3i1p1 forced HIRHAM simulation “v2” is a new simulation where proper GHG concentrations changing with time are used as a contrast to “v1” that erroneously used the constant control level throughout the simulation. Therefore users should use v2.
2. As it is for point 1. “v2” is used for the HIRHAM simulation forced by MOHC-HadGEM2-ES.
3. As for the previous two points but here “v3” is used for the NorESM driven simulation. A previous “v2” version including also an error in the vertical interpolation when preparing the boundary files also exists.

• KNMI

1. For the MOHC-HadGEM2-ES forced RACMO simulation v2 is a new simulation where a big error in SST-remapping from the HadGEM-grid to the RCM-grid in v1 was corrected. The erroneous v1-simulation has been unpublished from the ESGF.
2. For the CNRM-CM5 simulation v2 is a new simulation replacing the old now with input data taken from pressure levels instead of model levels. The originally provided model level fields from CNRM were wrong.

• SMHI

1. Two MPI-driven scenario runs were rerun in 2016 as there had been problems with a restart file and as there was an error in the snow diagnostics in the original run. The reruns were labelled v1a.

• CNRM

1. For the CNRM-CM5 simulation v2 is a new simulation replacing the old now with input data taken from pressure levels instead of model levels. The original provided model level fields from CNRM were wrong.

File naming conventions

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

• <variable> is a short variable name, e.g. “tas” for ”temperature at the surface”
• <driving-model> is the name of the model that produced the boundary conditions
• <experiment> is the name of the experiment used to extract the boundary conditions
• <ensemble-member> is the ensemble identifier in the form “r<X>i<Y>p<Z>”, X, Y and Z are integers
• <rcm-model> is the name of the model that produced the data
• <rcm-run> is the version run of the model in the form of "vX" where X is integer
• <time-frequency> is the time series frequency (e.g., monthly, daily, seasonal) 
• the <temporal-range> is in the form YYYYMM[DDHH]-YYYY[MMDDHH], where Y is year, M is the month, D is day and H is hour. Note that day and hour are optional (indicated by the square brackets) and are only used if needed by the frequency of the data. For example daily data from the 1st of January 1980 to the 31st of December 2010 would be written 19800101-20101231.