Open jesusff opened 11 months ago
Reconsidering this approach after the difficulties to develop ad hoc ESGF search interfaces for each activity (see #3).
We could add the FPS stage info to the version_realization
element (e.g. v1-s0r1), because we really need to distinguish Stage-0 file names from the same models under Stage-1 (evaluation). For the rest of the stages there would be no filename overlap, so we could just go for the standard v1-r1, or have v1-s1r1 and v1-s2r1. The only overlap could happen for the intermediate EUR-12 domain, that would be indistinguishable from a standard EURO-CORDEX run (if using the same model config). We could overcome this by having the FPS name also in the version_realization element, with a building rule such as v1-fpsurbrcc-s0r1.
We could explain the meaning of such a string in a global attribute version_realization_info
. And still consider having an experiment_id
attribute, even if not promoted to the DRS of files and paths. In combination with particular FPSs promoted to CORDEX activities (see #4), this would make the FPS DRS fully compatible with that of DD.
In order to have unique filenames for different experiments. We need some DRS elements to define these experiments and they need to be promoted to the file and directory names. One way to do it without adding new underscore-separated elements to the filename is to code them in the
version_realization
element. This was done, for instance, in the FPS-CONV, introducing version strings such as fpsconv-x1n2-v1, where the x1n2 part had to do with the nesting strategy.In CORDEX-CMIP6, the equivalent DRS element is the _versionrealization, which typically looks like
v1-r1
. Here, v1 refers to a version number in the sense of deprecation of earlier versions and r1 is a realization in the sense of perturbing the initial conditions. For FPS-URB-RCC, we could extend this element by using a building rule such as: