Page History

...

The CMIP6 data archive is distributed through the ESGF. A quality-controlled subset of CMIP6 global climate projection data are made available through the Climate Data Store (CDS) for the users of the Copernicus Climate Change Service (C3S). Dedicated ESGF data nodes are used for C3S in France (at IPSL) and in Germany (DKRZ).  Similarly, the decadal climate prediction project (DCPP) data in the Climate Data Store (CDS) are a targeted, quality-controlled subset of the DCPP commissioned by C3S. The published datasets are the ones which took part on the C3S sectoral demonstrator service (see details at https://climate.copernicus.eu/sectoral-applications-decadal-predictions) 

Decadal Climate Prediction Project Data in the CDS

...

The DCPP experiments published in the CDS, are a suite of overlapping simulations that are initialised every year throughout the duration of the start-date range specified by the experiment. The simulations begin in November November to allow for DJF (December, January, February) seasonal averages to be calculated. There are 10 simulations (ensemble members) for each start-date (called "Base year" in the CDS form), except for the MPI-ESM1-2-LR model which has 16 ensemble members.

The start-date ensemble is reflected in the DCPP data naming convention with the addition of a s<yyyy> start-date ensemble identifier. Please note that the conventional CMIP6 ripf ensemble identifiers are omitted for this particular dataset since all the ensemble members are concatenated into one file.

See some more more details in the File naming conventions and In-file metadata modifications sections below.

Practical details of the published data

In the table below some practical details of the data is shown including the base year (or start year) period covered and the number of ensemble members. For each start year there are (at least) 10 years of corresponding hindcast or forecast data available. Hindcast and forecast start years are not distinguished in the CDS form. Please note that the ensemble members are not available individually, but they are concatenated into one file while the data is downloaded, and generally users are encouraged to use all members instead of selecting one member of the predictions. 

*Note: Since hindcast and forecast data begins in November, the actual period the data covers includes only November and December for each start year, however the last year includes November and December. For example, for the 1960 start year, 1960 includes November and December and 1961 - 1970 have full coverage. 

INSTEAD, NEW TABLE PROPOSED:

*Note: Since hindcast and forecast data begins in November, the actual period the data covers includes only November and December for each start year, however the last year includes November and December. For example, for the 1960 start year, 1960 includes November and December and 1961 - 1970 have full coverage. 

Parameter listings

Data for the dcppA-hindcast experiments and the dcppB-forecast experiments will include parameters at monthly and daily resolution as described in the tables below. The parameter descriptions presented here are harvested from the CMIP6 Data Request via the CLIPC variable browser.

...

1. CF-Checks: The CF-checker tool checks that each NetCDF4 file in a given dataset is compliant with the Climate and Forecast (CF) conventions, compliance ensures that the files are interoperable across a range of software tools.
2. PrePARE: The PrePARE software tool is provided by PCMDI (Program for Climate Model Diagnosis and Intercomparison) to verify that CMIP6 files conform to the CMIP6 data protocol. All CMIP6 data should meet this required standard however this check is included to ensure that all data supplied to the CDS have passed this QC test.
3. nctime: The nctime checker checks the temporal axis of the NetCDF files. For each NetCDF file the temporal element of the file is compared with the time axis data within the file to ensure consistency. For a time-series of data comprised of several NetCDF files nctime ensures that the entire timeseries is complete, that there are no temporal gaps or overlaps in either the filename or in the time axes within the files.
4. Errata: The dataset is checked to ensure that no outstanding Errata record exists.
5. Data Ranges: A set of tests on the extreme values of the variables are performed, this is used to ensure that the values of the variables fall into physically realistic ranges.
6. Handle record consistency checks: This check ensures that the version of the dataset used is the most recently published dataset by the modelling centre, it also checks for any inconsistency in the ESGF publication and excludes any datasets that may have an inconsistent ESGF publication metadata.
7. Exists at both partner sites: It is asserted that each dataset exists at both partner ESGF data nodes at IPSL and DKRZ.

It is important to note that passing these quality control tests should not be confused with validity: for example, it will be possible for a file to pass all QC steps but contain errors in the data that have not been identified by either data providers or data users.

...

• A “realization” variable is added, to represent the ensemble member
• The “sub_experiment_id” global attribute is adjusted to include the start year and month of the simulation
• A “reftime” variable is added, representing the start time of the simulation
• A “leadtime” coordinate variable is added, which is the prediction range of the forecasts: this is calculated from the “reftime” and the valid times from the existing time variable
• The "long_name" attribute of the "time" coordinate is updated to "valid_time". 

...

Subsetting and downloading data

CDS users are able to apply subsetting operations to CMIP6 decadal datasets. This mechanism (the "roocs" WPS framework) runs at each of the partner sites: IPSL and DKRZ. The WPS can receive requests for processing based on dataset identifiers, a temporal range, a bounding box and a range of vertical levels. Each request is converted to a job that is run asynchronously on the processing servers at the partner sites. NetCDF files are generated and the response contains download links to each of the files. Users of the CDS will be able to make subsetting selections using the web forms provided by the CDS catalogue web-interface. More advanced users will be able to define their own API requests in the CDS Toolbox that will call the WPS. Output files will be automatically retrieved so that users can access them directly within the CDS.

...