ACCESS-ESM1.6 piControl Evaluation – ILAMB, ESMValTool, and Variable Mapping

CMIP7 CMIP7 evaluation
, , ,
1

Hi Everyone,

We’ve been working with the output from the ACCESS-ESM1.6 piControl spin-up run, available at:

/scratch/p66/pjb581/access-esm/archive/pi_concentrations-expt-c55f7217

There’s been ongoing discussion around evaluating these outputs using ILAMB and ESMValTool. @RhaegarZeng is currently preparing an ILAMB workflow to process and assess the data.

In parallel, I’ve been developing a lightweight version of MOPPeR designed for use within a Python/Jupyter environment on ARE, compatible with tools like ESMValTool. It’s still in early development (v2.0.0-alpha0), and available here:
:backhand_index_pointing_right: GitHub - ACCESS-NRI/ACCESS-MOPPeR: ACCESS-MOPPeR

As expected, there are still uncertainties around the output conventions—for example, final file structure, naming, and how many variables appear per file. The atmospheric data appears relatively straightforward (aside from a few missing variables—see below), but the ocean and sea-ice components remain more complicated due to the CMOR requirement to define grid cell bounds. I’m currently using the supergrid definition (thanks to @dougiesquire for flagging that), but ideally, this info would be embedded in the ESM1.6 output or linked via a unique grid identifier @Aidan.

STASH to CMIP Mapping

To progress the CMORisation workflow, we need a robust mapping from ACCESS-ESM1.6 STASH codes to CMIP variable names. So far, I’ve been referencing outputs from APP4 and MOPPeR v1 (developed for ACCESS-ESM1.5), but it looks like some STASH codes and output variable definitions have changed in ESM1.6.

I’ve put together a working spreadsheet listing the core variables needed for a baseline CMIP submission (i.e. the minimum required for FastTrack):
:link: ESM1-6_CMIP7_Mapping.xlsx - Google Sheets

If you or your team could help review and update the mapping or calculations, that would be very helpful.
For reference, the mappings currently used by MOPPeR v2.0.0-alpha0 are here:
:link: ACCESS-MOPPeR/src/access_mopper/mappings at v2 · ACCESS-NRI/ACCESS-MOPPeR · GitHub

Clear documentation of ACCESS-ESM1.6 outputs is becoming urgent—both for evaluation purposes and to support CMIP submission. Any input, corrections, or suggestions from the community would be greatly appreciated! @ClareCR

@clairecarouge @cbull @heidi @Aidan @ClareCR @inh599 @RachelLaw @tiloz @arnoldsu @anton @anton @MartinDix @kdruken

Thanks all!

1 Like
2

@rbeucher I had a very quick look and there is something weird. The “fld” variables seem to be shifted between the Excel table and the CMIP6 json mapping.

For example:

  • json has Amon.ci with fld_s05i269 but the Excel does not have ci and has fld_s05i269 for Amon.cl
  • json has Amon.cl with fld_s02i261 but Excel has Amon.cli with fld_s02i261
    etc.

I have no idea which one is correct.

3

I have corrected (I Think). The json files should be correct.

But the idea is to have a mapping for ESM1.6 so please don’t rely on previous information too much. We want to double check everything

1 Like
4

CICE can output the lat/lon bounds if desired. They should be the same as the ones from the supergrid, although it would be worth double checking.

In general including grid information as diagnostic output means a lot of repetition, so an identifier and a single grid file is better if possible.

the core variables needed for a baseline CMIP submission (i.e. the minimum required for FastTrack):

Are we planning on saving this set of variables during spin-up ? For experiments, I assume we want notably more than the minimum (e.g. SIMIP asks for additional variables at several tiers saved during running the standard experiments).

If you or your team could help review and update the mapping or calculations, that would be very helpful.

If we use CICE5, it will be a 1:1 mapping for Sea-Ice . i.e. the sea-ice variables can be output using the CMOR names.

1 Like
5

We can also output the grid into a separate file with MOM. But I’m curious what is the issue with using the input supergrid?

I agree with @anton that it is preferable not to include the full grid information in every output file.

Are you only needing assistance with variable name mappings for the UM? Similar to CICE, MOM allows outputting diagnostics using the CMOR names.

6

No issue with using the supergrid if it is identified in the output metadata.
I think we need to have a DOI for the grid and publish it somewhere.
I need assistance with mapping all variables. I have not seen CMOR names in the outputs for MOM but if the intent is to use them, that’s good news.

1 Like
7

Hi all - I just wanted to quickly add that @ClareCR and I are working on a template to kickstart the documentation we think would be best practice to accompany model releases. We’re meeting with @rbeucher and @MartinDix this week to do a first pass with them to check it’s fit for our needs and will then circulate more broadly.

8

@rbeucher - great that you are making progress with this.

I’m guessing we need to form some small groups to tackle the spreadsheet e.g. atmosphere/land/ocean etc. This is how we managed it for CMIP6.
In most cases the ESM1.5 information will be correct, though for the land we will need some updates as we expect to use additional plant functional types compared to ESM1.5. For example, in the Lmon .json mapping, there are variables for c3 and c4 land fraction which list the tile numbers to be included.
As @anton mentioned with regard to SIMIP, we will also need to consider what variables we need for other MIPs that are additional to the core FastTrack list.

1 Like