r-realisation
i-initialisation method
p-physics
f-forcing

我检查了概述论文< A href="https://www.geosci-model-dev.net/9/1937/2016/" rel="nofollow noreferrer">Eyring et al. (2016)，但它没有提到任何关于VARIANT-ID的内容。我也检查了ESGF提供的其他文件，但没有找到任何信息。这里有人知道我在哪里可以找到CMIP6数据集VARIANT-ID的详细信息吗?< / p >

例如，可以在< A href="https://pcmdi.llnl.gov/CMIP6/Guide/modelers.html" rel="noreferrer">CMIP6 Modelers参与指南。< / p >

Edit: Following up Deditos' comment, I quote the respective section of the DRS document below:

For a given experiment, the realization_index, initialization_index, physics_index, and forcing_index are used to uniquely identify each simulation of an ensemble of runs contributed by a single model. These indices are defined as follows:

• realization_index = an integer (≥1) distinguishing among members of an ensemble of simulations that differ only in their initial conditions (e.g., initialized from different points in a control run). Note that if two different simulations were started from the same initial conditions, the same realization number should be used for both simulations. For example if a historical run with “natural forcing” only and another historical run that includes anthropogenic forcing were both spawned at the same point in a control run, both should be assigned the same realization. Also, each so-called RCP (future scenario) simulation should normally be assigned the same realization integer as the historical run from which it was initiated. This will allow users to easily splice together the appropriate historical and future runs.
• initialization_index = an integer (≥1), which should be assigned a value of 1 except to distinguish simulations performed under the same conditions but with different initialization procedures. In CMIP6 this index should invariably be assigned the value “1” except for some hindcast and forecast experiments called for by the DCPP activity. The initialization_index can be used either to distinguish between different algorithms used to impose initial conditions on a forecast or to distinguish between different observational datasets used to initialize a forecast.
• physics_index = an integer (≥1) identifying the physics version used by the model. In the usual case of a single physics version of a model, this argument should normally be assigned the value 1, but it is essential that a consistent assignment of physics_index be used across all simulations performed by a particular model. Use of “physics_index” is reserved for closely-related model versions (e.g., as in a “perturbed physics” ensemble) or for the same model run with slightly different parameterizations (e.g., of cloud physics). Model versions that are substantially different from one another should be given a different source_id” (rather than simply assigning a different value of the physics_index).
• forcing_index = an integer (≥1) used to distinguish runs conforming to the protocol of a single CMIP6 experiment, but with different variants of forcing applied. One can, for example, distinguish between two historical simulations, one forced with the CMIP6-recommended forcing data sets and another forced by a different dataset, which might yield information about how forcing uncertainty affects the simulation.

Each data provider can assign whatever positive integers they like for the realization_index, intialization_index, physics_index, and forcing index. For each source/experiment pair, however, consistency (in these indices) should be maintained across each parent/child pair whenever sensible (so that, for example, both the ScenarioMIP child and its “historical” parent simulation would be assigned the same set of index values for realization, initialization, and physics); the integer 1 should normally be chosen for each of these in the case of a single variant or for the primary variant (if there is one). This is only a suggestion, however; there should be no expectation on the part of users that every model will have a value of 1 assigned to any of the r, i, p, f indices, and even if a 1 is assigned it does not imply that it is the primary variant. Note also that a child spawned by a control run will not necessarily have the same “ripf” value as the control, since, for example, multiple realizations of an experiment will branch from the same control.

Note that none of the “ripf” indices can be omitted.

Example of a variant_label: if realization_index=2, initialization_index=1, physics_index=3, and forcing_index=233, then variant_label = “r2i1p3f233”.