Building rule for `version_realization`

[jesusff]

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:

= fpsurbrcc--v1-r1 E.g. **fpsurbrcc-s0e1-v1-r1** using the `experiment_id`s in: https://github.com/FPS-URB-RCC/cordex-cmip6-cv/blob/ab88a7e51342c12ac3ad6f236366cb0b7dabdf0f/CORDEX-CMIP6_experiment_id.json#L1-L5 In the directory hierarchy this approach would split files according to experiment "too late" though, since the *version_realization* element comes after the model name and one would need to look for a given experiment files in each model version. https://github.com/FPS-URB-RCC/cordex-cmip6-cv/blob/ab88a7e51342c12ac3ad6f236366cb0b7dabdf0f/CORDEX-CMIP6_DRS.json#L3 This is fundamentally different from FPS-CONV, where the nesting strategy was just a configuration detail of the model, and not separate experiments. In FPS-CONV there was a single experiment (decadal time-slice simulations differing only in the driving model and scenario). For FPS-URB-RCC we could split the path earlier, right after the activity_id: ```xml //////... ``` E.g. `/cordex/cmip6/fps/fpsurbrcc/s0e1/PAR-3/...`

[jesusff]

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.