There is a number of Tier 3 datasets (see status in the table below) for which we (@hb326 and myself) got the approval from data providers to allow access to our users on shared machines (e.g. DKRZ, Jasmin, ...). At the moment, CMORized data stored on Levante are restricted to group members (i.e. core developers) if Tier 3 and with read access to anyone if Tier 2. To ease data access for our users, we first need to check with data providers if more Tier 3 datasets could be labelled Tier 2 instead. This would allow us to open up the access at DKRZ and include more datasets into the synchronization pipeline between main HPC centers where ESMValTool is developed (see #2630 for separate discussion).

Changing the Tier of a dataset may lead to various backward incompatibility issues. Recipes using that dataset will need to be updated. Users having their local pool of CMORized data will also need to move some datasets to Tier2 on their own. A possibility to circumvent that could be to make the tier key in recipes optional. See ESMValGroup/ESMValCore#2112 for separate discussion.

On the Tool side, a number of things will need to be done when moving a dataset from Tier3 to Tier2. Here is a tentative checklist:

• Open a GitHub issue about the affected dataset
• Update the documentation, the CMORizer and rerun the CMORizer (or at least change the tier attribute in the metadata).
• Add an item to the review checklist to ask if recipe developers have used the right tier key for affected datasets
• Move the CMORized data in OBS/Tier2 (specific to DKRZ)
• Make a symlink to OBS/Tier3 to avoid breaking recipes under development (specific to DKRZ)
• Run the synchronization script to ship data to Jasmin and other connected systems where OBS/Tier2 data are mirrored (specific to DKRZ)
• Remove the symlink after 2 releases (specific to DKRZ)
• Move the corresponding raw data in RAWOBS/Tier2 (specific to DKRZ)
• Add a message to the log files that "Missing OBS data" could be due to the change of Tier and inform users what to do.