Implement consistent plot labelling in CMEW

[alistairsellar]

We want the outputs of CMEW to have consistent plot labels for all recipes (part 1 of user story #311).

This requires:

• Investigation of ESMValTool constraints and capabilities: Investigate the use of "alias" in ESMValTool recipes #288, Investigate whether arbitrary "dataset" identifiers work in ESMValTool #290
• Implementing a pipeline from CMEW to the recipe (Feed "label for plots" through as an "alias" in ESMValTool recipe #298) and from recipe to plots (Amend radiation budget recipe and diagnostic script on ESMValTool #302)
• Ensuring future CMEW recipes make use of the pipeline (Developer guidance: ensure all CMEW recipes make use of alias as plot labels #312)

(Note linked issue #312 to ensure that developer guidance ensures new CMEW recipes use alias.)

[NParsonsMO]

Overview of discussion held 08/12/25:

There are three separate (but related) entities that exist and are relevant to a future solution.

1. The unique suite ID (e.g. u-ab123). This tells CDDS where to find data on MASS.
2. The name of the standardised [i.e. post CDDS] dataset. This is assigned by CDDS, dependent on the command line call. It is also, separately, written into an ESMValTool recipe by CMEW.
3. A dataset "label", a helpful arbitrary string that labels lines and points in plots, to identify which dataset is being represented.

The current set up is that a CMEW user will provide a "model ID", and this is both what CDDS will call the standardised data and what most(?) ESMValTool recipes will label that data as in plots.

However, it is likely that CDDS (and perhaps ESMValTool) cannot take absolutely arbitrary strings as the name of standardised data, and so generating this automatically, based on the unique suite ID, would provide a way to remove this complication from the user.

• e.g., perhaps a specified MO-internal prefix [followed by any string of the right form] could be added to an "allow" list in CDDS
• or perhaps CMEW can modify an allowed list on the fly, which would remove any constraints.

Some ESMValTool recipes already allow for plots to be labelled with an "alias", which may or may not match the name of the dataset (see attached sub issue #288, "alias" is a facet created by ESMValCore). This would allow for the standardised data to be named systematically, but have a more descriptive string show in plots [see sub issue #288]. This alias is generated by ESMValCore if not explicitly defined, and may or may not be queried by the diagnostic scripts.

I suggest that

1. we set the user interface to take only "suite ID" and [optionally? *] "dataset label",
2. we set the CDDS run to automatically assign a name to the standardised data, such as
   UPDATE: I may have hyphens and underscores the wrong way round, check before implementation

- u_ab123 [the underscore is because I think ESMValTool needs underscores instead of hyphens]
- MO_int_U_AB123
- something similar in a form that works with CDDS.

3. we set the alias to be "dataset label" in the ESMValTool recipe.

Interim use of existing recipes and diagnostic scripts likely do one of

• already take an alias deliberately,
• do not take an alias and so label with the dataset name explicitly

Either of these will at least show the unique suite ID (maybe plus a few letters), both of which will be understandable to the scientist, until any desired amendments (likely minor, again see issue #288) are made to the diagnostic script.

*: If optional, we would need to not create the "alias" key in that dataset's section of the recipe in instances when it isn't provided.

[NParsonsMO]

If we go with feeling the label through as an alias, I wonder if the next step is to remove the model ID box from being user-configurable, and instead automate what CDDS will call the standardised dataset, which will presumably be some form of the suite ID?

[NParsonsMO]

Looks like the next step is to explore what is possible in terms of naming for CDDS.

We also need to find out whether end users want to be able to feed in an arbitrary string.

Current thought: it would be possible to re-use a generic dataset name (or as many names as we may want concurrent datasets ub a run), as long as the alias went through to everything, but this seems messy and risky.