ISIMIP3 simulation protocol

Table of Contents

The simulation protocol describes the simulation scenarios, input data sets and output variables necessary to participate in the ISIMIP3 simulation round.

Please select the simulation round (ISIMIP3a, ISIMIP3b) and the sectors you are interested in from the menu on the right. The page will then adjust to your selection. The parts of the protocol, which are specific to a simulation round or sector are marked accordingly.

Last updated: 28 September 2022

Commit hash: ca1e7833a2853d4abd18bd6cc0a5dd96785365f9

Direct link for this selection:

1. Introduction

1.1 General concept

The Inter-Sectoral Impact Model Intercomparison Project (ISIMIP) provides a framework for the collation of a consistent set of climate impact data across sectors and scales. It also provides a unique opportunity for considering interactions between climate change impacts across sectors through consistent scenarios.

ISIMIP is intended to be structured in successive rounds connected to the different phases of the climate model intercomparison CMIP (ISIMIP Mission & Implementation document).

The main components of the ISIMIP framework are:

1.2 Simulation round

The ISIMIP3a part of the third round framework is dedicated to i) impact model evaluation and improvement and ii) detection and attribution of observed impacts according to the framework of IPCC AR5 Working Group II Chapter 18. To this end all simulations are forced by observed climate and direct human forcing and a de-trended version of the observed climate allowing for the generation of a “no climate change” baseline (counterfactual, if available).

To ensure consistency between ISIMIP3a and ISIMIP3b as well as the different experiments within a simulation round, we require that modelling groups use the same version of an impact model for the experiments in ISIMIP3a and ISIMIP3b.

GCM-based simulations assuming fixed 2015 direct human influences for the future

The ISIMIP3b part of the third simulation round is dedicated to a quantification of climate-related risks at different levels of climate change and direct human forcing. The Group 1 simulations refer to the pre-industrial and historical period of the CMIP6-based climate simulations. Group 2 covers all future projections assuming fixed 2015 levels of direct human forcing and different future projections of climate (SSP1-2.6, SSP3-7.0 and SSP5-8.5). Group 3 simulations account for future changes in the direct human forcing and are intended to be started once the corresponding direct human forcing input data is available.

To ensure consistency between ISIMIP3a and ISIMIP3b as well as the different experiments within a simulation round, we require that modelling groups use the same version of an impact model for the experiments in ISIMIP3a and ISIMIP3b.

1.3 Simulation protocol

In this protocol we describe the scenarios & experiments, the different input datasets, the output variables, and how to report model results.

Throughout the protocol we use specifiers that denote a particular scenario, experiment, variable or other parameter. We use these specifiers in the tables below, in the filenames of the input data sets, and ask you to use the same specifiers in your output files. More on reporting data can be found at the end of this document.

2. Experiments & Scenarios

2.1 Experiments

In Table 2.1, we describe the different experiments for ISIMIP3. Each default experiment is defined by its climate related forcing (CRF) and the assumptions regarding direct human forcing (DHF). The associated specifications all have a label such as obsclim or histsoc that are provided in Table 2.1 and further specified in Tables 2.2 and 2.3. These specifiers are used in the file names of the corresponding input files and should also be used for the names of the output files (see report model results report model results). Sensitivity experiments are described as deviation from a default experiment and represented by labels that are used as a third specifier of the experiments. Their specific meanings are defined in Table 2.4.

Please note that the experiments are different for ISIMIP3a and ISIMIP3b and some are sector specific. You can use the menu on the top-right of the page to select the sumulation round and sectors you are interested in.

Note regarding models requiring spin-up

For models requiring spin-up, we provide 100 years of spinclim data which is identical with the first 100 years of the counterclim data. The files are located under ISIMIP3a/InputData/climate/atmosphere/spinclim at DKRZ and in the ISIMIP Repository. If more than 100 years of spin-up are needed, these data can be repeated as often as needed.

For historical runs, use the transclim climate time series, historical CO₂ concentration and varying DHF, for the transition period from spin-up to the start of the experiment (1850-1900). When using a longer spin-up period that (nominally) extends back further than 1850, please keep CO₂ concentration and DHF constant at 1850 level until reaching the year corresponding to 1850.

For experiments with fixed direct human influences (1901soc, 2015soc), the spin-up should be based on the 1901 DHF or 2015 DHF, respectively.

For sector-specific experiments without direct human influence (nat), the spin-up should not use any DHF as well.

For models requiring spin-up, please use the pre-industrial control data and CO₂ concentration and DHF fixed at 1850 levels for the spin up as long as needed.

Please note that the "pre-industrial control run" from 1601-1849 is part of the regular experiments that should be reported and hence the spin-up has to be finished before that.

For experiments with fixed year-2015 direct human influences (2015soc), spin-up should be based on the 2015 DHF.

For sector-specific experiments without direct human influence (nat), the spin-up should not use any DHF as well.

Please note that there is no "pre-industrial control run" from 1601-1849 for these experiments (2015soc, nat) and hence the spin-up links directly to the historical period.

2.2 Scenario definitions

Tables 2-4 describe the different scenarios for the different simulation periods as described in Table 1. They are used in the file names of the corresponding input files and should also be used for the names of the output files (see report model results).

General note regarding sensitivity experiments

The sensitivity experiments are meant to be deviations from the default settings. So for example if your model does not at all account for changes in CO₂ concentrations (no option to switch it on or off) the run should be labeled as “default” in the sensitivity specifier of the file name even if the run would be identical to the 1901co2 sensitivity setting.

The particular sensitivity scenario for an experiment is given in the experiments table below. For most experiments no sensitivity scenario is given, so the default label applies.

General note regarding sensitivity experiments

The sensitivity experiments are meant to be deviations from the default settings. So for example if your model does not at all account for changes in CO₂ concentrations (no option to switch it on or off) the run should be labeled as default in the sensitivity specifier of the file name even if the run would be identical to the 1850co2 sensitivity setting.

The particular sensitivity scenario for an experiment is given in the experiments table below. For most experiments no sensitivity scenario is given, so the default label applies.

3. Input data

The base directory for input data at DKRZ is:

levante:/work/bb0820/ISIMIP/

Further information on accessing ISIMIP data can be found at ISIMIP - getting started.

Note on mandatory datasets

Some of the datasets are tagged as mandatory. This does not mean that the data must be used in all cases, but if your models uses input data of this kind, we require to use the specified dataset. If an alternative data set is used instead, we cannot consider it an ISIMIP simulation. If the mandatory label is not given, you may use alternative data (please document this clearly).

The climate forcing input files can be found on DKRZ using the following pattern:

ISIMIP3a/InputData/climate/atmosphere/<climate-scenario>/global/daily/historical/<climate-forcing>/<climate-forcing>_<climate-scenario>_<climate-variable>_global_daily_<start-year>_<end-year>.nc

# ocean data for marine-fishery
ISIMIP3a/InputData/climate/ocean/<climate-scenario>/global/monthly/historical/<climate-forcing>/<climate-forcing>_<climate-scenario>_<climate-variable>_global_monthly_<start-year>_<end-year>.nc

The climate forcing input files can be found on DKRZ using the following pattern:

ISIMIP3b/InputData/climate/atmosphere/bias-adjusted/global/daily/<climate-scenario>/<climate-forcing>/<climate-forcing>_<ensemble-member>_<bias-adjustment>_<climate-scenario>_<climate-variable>_global_daily_<start-year>_<end-year>.nc

# ocean data for marine-fishery
ISIMIP3b/InputData/climate/ocean/uncorrected/global/monthly/<climate-scenario>/<climate-forcing>/<climate-forcing>_<ensemble-member>_<climate-scenario>_<climate-variable>_onedeg_global_monthly_<start-year>_<end-year>.nc  # 1° grid
ISIMIP3b/InputData/climate/ocean/uncorrected/global/monthly/<climate-scenario>/<climate-forcing>/<climate-forcing>_<ensemble-member>_<climate-scenario>_<climate-variable>_halfdeg_global_monthly_<start-year>_<end-year>.nc  # 0.5° grid

Note on ocean data availability

Variable availability is mainly based on the data published in ESGF and may vary between the CMIP experiments.

Some variables are available as extracted versions from vertically resolved data. Their variable names have been suffixed with -bot (ocean bottom), -surf (surface values) or -vint (vertically integrated), respectively.

Note on ocean data availability

Some variables are available as extracted versions from vertically resolved data. Their variable names have been suffixed with -bot (ocean bottom), -surf (surface values) or -vint (vertically integrated), respectively.

Note on climate forcing priority

The priority for the different climate forcing datasets is given in the last column of Table 5. If you cannot use all climate forcing datasets, please concentrate on those with a higher priority.

3.2 Direct human forcing

3.3 Static geographic information

4. Output data

4.1 Output dimensions

ISIMIP output variables are usually reported with the dimensions (time,lat,lon). For variables with a number of levels (e.g. layers or depth), an alternative set of dimensions is given in the comment column in the table below. More information about level dimensions can be found here and here on the ISIMIP webpage.

Note on agriculture output

For agricultural output, variables are to be reported with the dimensions (time,lat,lon) where the time axis' unit is growing seasons since 1901-01-01 00:00:00 resp. growing seasons since 1661-01-01 00:00:00 for all variables unless these are reported on a transient time axis, e.g. 'soilmoist1m'. In many cases growing seasons are equivalent to years, as there is always only one planting event per year. However, due to temperature-sensitive growing season lengths, the growing seasons are not fully equivalent to years and users should note the difference. Reported variables on start and end of the growing season are supplied to allow allocating events to transient time axes if desired.

Many variables are defined per area (unit m-2). Typically, and unless otherwise defined, the corresponding reference area is the land area of the grid cell, excluding any water bodies. However, in some cases, it may be necessary or meaningful to report a variable relative to the continental area (including inland water bodies, lakes etc...). For example, evaporation could relate to the land area (excluding water bodies etc.), or to the continental area if the model evaporation occurs over both over land and over water. Also, for some variables, the "per PFT" reporting allows modellers to indicate whether inland water bodies are included in the model or not, and hence, what reference area the variable refers to. In such cases, please specify the reference area in a NetCDF global attribute (e.g. :reference_area = "continental area (including inland water bodies)").

4.2 Output variables

4.3 Sector specific identifiers

Crop priority and naming

Irrigation

Harmonization

Species

Forest stands

Lake sites

A document with additional information is maintained by the sector coordinators and provided at https://docs.google.com/spreadsheets/d/1UY_KSR02o7LtmNoOs6jOgOxdcFEKrf7MmhR2BYDlm-Q/edit#gid=555498854.

Ocean regions

Catchment gauging stations

No sector specific identifiers are available for this selection of simulation round and sectors.

4.4 Sector specific notes

Reporting per growing seasons

To resolve potential double harvests within one year, crop yields should be reported per growing season and not per calendar year. Thus, in the NetCDF output files, do not use a time dimension but instead a unitless coordinate variable with integer values; more information on how to construct these files is given below and on the ISIMIP website (https://www.isimip.org/protocol/preparing-simulation-files/).

Cumulative growing season variables such as, e.g., actual evapotranspiration or precipitation are to be accumulated over the growing season. The first season in the file (level=0) is then the first complete growing season of the time period provided by the input data without any assumed spin-up data, which equates to the growing season with the first planting after this date. To ensure that data can be matched to individual years in post-processing, it is essential to also provide the actual planting dates (as day of the year), actual planting years (year), anthesis dates (as day of the year), year of anthesis (year), maturity dates (day of the year), and year of maturity (year). This procedure is identical to the GGCMI convention (Elliott et al., 2015, https://doi.org/10.5194/gmd-8-261-2015).

Information about PFT-specific outputs

  • Unless otherwise defined, variables in ISIMIP should be reported relative to the grid cell land area.
  • The output provided per Plant Functional Type (PFT) should be expressed relative to the respective PFT area so that e.g. sum(gpp-pft*pft-pft)=gpp-total.
  • When your model allows several PFTs to grow on the same area and hence the total cover fraction can be more than one, please scale the PFT area to one and report this step in the model documentation on the ISIMIP homepage.
  • When your model grows the same PFT on different land-use classes, e.g. the same c3-grass represents grasses growing on natural grasslands, pasture and possible even as crop, please differentiate this in your output by defining land-use specific PFT such as c3-grass-pasture, c3-grass-natural, c3-grass-crop and report this in model documentation on the ISIMIP homepage.

Additional instructions for the health sector

  • If different realizations of the model are applied, then these should be indicated by the specifier <r>. E.g. to reflect a central, upper, and lower estimate of the ERF: <r> = lower, central, upper. Please explain the meaning of these realizations in the online model documentation; contact the ISIMIP coordination team in case of questions.
  • If data are disaggregated e.g. by age group, gender, etc., they should be reported along an additional dimension, described by an auxiliary coordinate variable, in the NetCDF files. See the example provided at https://www.isimip.org/protocol/preparing-simulation-files/.
  • For local (non-gridded) data, locations (cities/regions/countries) should be reported along an additional dimension called location, with the location name given as string in an auxiliary coordinate variable called location_name, in the NetCDF files. In addition, coordinates of the location should be reported in auxiliary variables called location_lat and location_lon. See the example provided at https://www.isimip.org/protocol/preparing-simulation-files/. The <region> specifier in the file name should be set to local. For gridded data, the <region> specifier in the file name should be global or indicate a region or country.

No sector specific notes are available for this selection of simulation round and sectors.

5. Reporting model results

The specification on how to submit the data, as well as further information and instructions are given on the ISIMIP website at:

https://www.isimip.org/protocol/preparing-simulation-files

It is important that you comply precisely with the formatting specified there, in order to facilitate the analysis of your simulation results in the ISIMIP framework. Incorrect formatting can seriously delay the analysis. The ISIMIP Team will be glad to assist with the preparation of these files if necessary.

To ensure consistency between ISIMIP3a and ISIMIP3b as well as the different experiments within a simulation round, we require that modelling groups use the same version of an impact model for the experiments in ISIMIP3a and ISIMIP3b. If you cannot fulfill this, please indicate that by using a suffix for your model name (e.g. simple version numbering: MODEL-v1, MODEL-v2 or following semantic versioning: MODEL-2.0.0, see also reporting model results).

This versioning does not only apply to changes in the computational logic of the model, but also to input parameters, calibration or setup. If model versions are not reported, we will name them according to the simulation round (e.g. MODEL-isimip3a). We require the strict versioning to ensure that differences between model results are fully attributable to the changes in model forcings.

File names consist of a series of identifier, separated by underscores. Things to note:

Please name the files according to a sector specific pattern:

and replace the identifiers with the specifiers given in the tables of this document. For questions or clarifications, please contact info@isimip.org or the data managers directly (isimip-data@pik‐potsdam.de) before submitting files.