Esmvaltool: Variables missing for Autoassess area metrics

[valeriupredoi]

Bunch of variables defined previously by stash and non-CMOR names in the original Autoassess package are untranslatable by me for the newly integrated ESMValTool autoassess metrics. A list detailing them is here: https://github.com/ESMValGroup/ESMValTool/blob/REFACTORING_autoassess/esmvaltool/diag_scripts/autoassess/AUTOASSESS_VARS.txt or in esmvaltool/diag_scripts/autoassess/AUTOASSESS_VARS.txt on any branch after merge in main. Need help, please :smile:

[valeriupredoi]

The file with missing variables (including comments from @alistairsellar and current fixes)
AUTOASSESS_VARS.txt
has been removed from the core binary repo and I am attaching it here, in its latest version

[valeriupredoi]

This is a notification of impending doom :grin: Just kidding, I'm starting to look into the review of the existing autoassess metrics in ESMValTool and @alistairsellar suggested we look at u-az513 vs u-as371 UKESM suites with data currently on Met Office's MASS filesystem. Whereas getting data to Jasmin from MASS is piece of cake using the moo :cow: protocol, I need to know specifically what __streams__ to grab for each of the variables for each of the two suites - @alistairsellar can you help a bro?

[alistairsellar]

Hi @valeriupredoi, is the purpose of this issue to enable us to define custom CMOR variables for variables that don't have CMOR equivalents?

If so, I propose that we define these per-diagnostic as each one is ported? I think it needs the input of each area specialist, so would be most efficient to define at the time that they are working on porting the diagnostic.

OK with you?

[valeriupredoi]

sounds like a very solid plan @alistairsellar :+1: :beer: So am closing this, feel free to reopen!