Allow for domain-specific studies to be included/excluded

[jesusff]

Copying here a request from S. Somot:

I would like to implement for the MED GCM selection procedure. With respect to the current situation, I would like remove one study, add some new ones and change some of the existing. I think that CMIP6_studies_config.yaml is the right file to use but I don't know how to code it in the file.

For example, if I'd like to remove Dobler SST rmse EUR and add

Atlas Dtas MED DJF for the ssp370 Atlas Dtas MED JJA for the ssp370 Atlas Dpr MED DJF for the ssp370 Atlas Dpr MED JJA for the ssp370

Being able to select one by one the "key" of the selected criteria would be perfect. In this case, using only the spatial scope is not enough.

[jesusff]

This is not implemented, but I see several options. The simplest for the moment would be to open a branch for the MED files so you can disable there the columns that you like, with the standard procedure. For example, there are several entries disabled here: AtlasIPCC.yaml

The problem with changing this in the main branch is that the entry would be disabled for all domains. Thus, the use of the separate branch, where I could produce the tables for MED and feed them back to the main website.

In the long term, this is not ideal. The option you propose, i.e. to have entry like

disabled_by_domain:
   MED:
     - Dobler SST rmse EUR
     - Atlas Dtas MED DJF
     - Atlas Dtas MED JJA
     - Atlas Dpr MED DJF
     - Atlas Dpr MED JJA

in CMIP6_studies_config.yaml would be one option. But this would be hard to maintain if the "keys" change and there is no track of why they were disabled.

Another way would be to have a e.g. disabled_MED field in the study yaml file itself. In this way, it can be explained there why it is disabled and other domains can consider also to disable it (maybe finally leading to a "disabled" field which would remove the entry for all domains). I mean something like this:

disabled_MED:
     cause: not_relevant
     comment: >
       This metric is not relevant for Med-CORDEX because ...

what do you think? I can open the branch for MED anyway and we can start with the fast approach and develop there the implementation of this last one. When this is ready, we can merge it back to the main branch for other domains to benefit as well.

[jesusff]

ok for implementing the fast approach that is to say opening a new branch for MED in which I will be able to modify all the yaml file to activate or deactivate the metrics I would like. On the long term, I would prefer to use the CMIP6_studies_config.yaml as the main driving file, and not to "disabled" some metrics as you proposed but more to activate them. So the users will do a positive action in selecting the metrics he/she wants to implement for a given domain. It will be easier to read and understand as we will have the list of activated metrics in CMIP6_studies_config.yaml. The problem of "changing keys" for a given yaml file is indeed an issue

OK, the new branch is ready https://github.com/WCRP-CORDEX/cmip6-for-cordex/tree/MED

I realized that the problem that you posted is bit more complex than I initially thought, since you plan to activate particular scenarios of a given score. Maybe it is advisable to use the ssp370 also in EURO-CORDEX, since this is the first scenario to consider.

On the other hand, the spatial scope filter was devised to select automatically all scores relevant for a given domain. These are expected to be too many, so the user should be essentially removing some of them to make the table more manageable. When new metrics are added, they would appear on the table, so the user might need to decide whether to keep them or not. Otherwise, new metrics would go unnoticed.

Anyway, lets keep thinking on solutions tailored for the different domains. Both options should be easily implemented.

[jesusff]

This is ready to merge, since domain-specific studies can now be handled using the disable_DOMAIN: mechanism. The old tables are reproduced and also the MED one (not shown in the website until merged to main). The only difference in the existing tables is the use of ssp370 instead of ssp585 in both the EUR and MED tables (see 57c2627)

[sam-somot]

I'm still quite new to github. I tried to approve the review without making mistakes in order to allow you to merge. Very good if we can have only one branch to maintain. The disabled_DOMAIN seems a good solution

[jesusff]

Thank you, @sam-somot

This was also a test to see if you could review pull requests and it worked fine. The review process will be simpler when there are just additions or small modifications to yaml files. In this case there were quite a few changes to the code as well. I will merge now and open specific issues with some questions you posted above.