ACCESS-ESM1.6 scope and use for CMIP7 Fast Track

CMIP7 CMIP7 Models
1

ACCESS-ESM1.6 scope

ACCESS-ESM1.6 needs to be defined and tested during the remainder of 2024 so that spin-up can begin in 2025. Any upgrades from ACCESS-ESM1.5 will need to be relatively simple to implement and test. Please use this topic to

  • suggest model improvements
  • report any bugs that should be fixed
  • note any additional diagnostics that would be useful (or were incorrect for CMIP6).

Already in scope are

  • updates to WOMBAT, led by @pearseb
  • updates to the simple land-use scheme to better account for wood harvest, led by @tammasloughran
  • potential use of ACCESS-CM2 CABLE settings and use of the CABLE3 codebase instead of CABLE2.4

CMIP7 Fast Track experiments
Please also use this topic to indicate if you are interested in helping to run and analyse any of the Fast Track experiments. Listing the experiments that are of most interest to you would be really helpful. More information about the experiments is available
here - AR7 Fast Track experiment viewer.

2

Hello Rachel, all,

Thank you for leading this. It is great to see improvements to CABLE and WOMBAT! I understand the Fast track timeline is challenging and the ultimate goal is the development of the ACCESS-ESM3. Since there is more focus on the emission scenarios and bgc for CMIP7 and fast track, maybe improvements on the bgc only are sufficient.
We are planning to participate in PMIP with the LIGabrupt, but without much excitement. The ACCESS-ESM1.5 performances for the LIG were relatively good, with maybe too much sea-ice in the Arctic and very low sea-ice in the SO. The UK group suggests that the inclusion of melt-ponds in the sea-ice model is crucial to simulate changes in the Arctic sea-ice.
In our other experiments (i.e. AMOC weakening, 49ka exp), we have noted a very slow (~600 yrs) response of the SO sea-ice and little sensitivity (a slight sea-ice increase instead of decrease for an AMOC weakening and relatively small sea-ice increase at 49ka).
This leads me to wonder whether there would be merit in replacing CICE4.1 with CICE5.1.2 in the ACCESS-ESM1.6. That would mean that the ACCESS-ESM1.6 would then have the same structure as the ACCESS-OM2 series… just floating an idea really, realizing that the coupling to the UM/CABLE and re-tuning involved might not make it straightforward.

In terms of helping with the fast track in 2025, we can do the LIG abrupt, could consider the abrupt0p5CO2 and/or other experiments of the scenarioMIP/C4MIP that could help.

1 Like
3

Use the inland basin and lake evaporation corrections to river runoff from CM2?

4

Is this the same setup as CM2 @MartinDix? In which case would it be pretty straightforward to use in an ESM1.6, or were the UM versions different enough that the modifications to CICE5 wouldn’t be compatible?

5

@RachelLaw it wasn’t named in your request, but the build and deployment infrastructure should also be included in this plan. And that relies a bit on what code upgrades are required. The closer the upgrades are to existing models (like OM2 and CM2) the easier it will be.

How different code is incorporated is also important, particularly anything that is shared between multiple models but is a sub-component. I’m thinking particularly of WOMBAT.

6

@Aidan - another aspect is making sure we can run all the experiments under payu rather than the script-based runs that some of us are still using for ACCESS-ESM1.5.

@sofarrell will reply about CICE - basically the UM version means we wouldn’t get the advantages of newer CICE.

7

@Aidan, a few of us (@RachelLaw, @tiloz, @matthew.chamberlain, @pearseb, @AndyHoggANU) met to chat about this last week. The gist is this:

  • The WOMBAT code as it is currently used in ACCESS-OM2 and ACCESS-ESM1.5 is written directly into MOM5 src as a tracer package. Let’s call this the MOM5-version of WOMBAT.
  • ACCESS-NRI has rewritten WOMBAT so that it can be used by both MOM5 and MOM6. This is being tested with MOM6 in ACCESS-OM3. Let’s call this the generic-version of WOMBAT.
  • At the same time, @pearseb has been doing his science developments into the MOM5-version of WOMBAT.
  • The intention is to use the generic-version of WOMBAT in ACCESS-ESM1.6, but some additional work is still needed to couple it. In the meeting, it was decided that ACCESS-NRI would prioritize this work. At the same time, @pearseb will continue his developments in the MOM5-version (I think the code is mostly frozen now and he’s testing?). The hope is that both efforts will finish in time to port @pearseb’s developments into the generic-version of WOMBAT and use that in ACCESS-ESM1.6. This will mean changes to the way things are built relative to current ACCESS-ESM1.5, so all this will need to be done in consultation with you and your team.

ADDED: to be clear (or not) my plan is also to update ACCESS-ESM1.5 and ACCESS-OM2 to use the generic-version of WOMBAT, so there will be new releases of those.

1 Like
8

Very much yes.

9

HI @LaurieM, @RachelLaw,

It’s a nice idea to upgrade our models to align with ACCESS-OM2, but, it’s the coupling to the UM7.3 that’s the issue. We can couple CICE5.1.2 to UM7.3 but we would only get the old zero layer thermodynamics we had in CICE4.1. as the coupling for multilayer ice came in later in GA7 Met Office version.

This zero layer ice scheme has just been removed entirely from the CICE6.5 code after being depreciated in the last few versions that’s how old and out of date it is.

In terms of melt pond schemes there is a simple allowance for melt ponds in the reduction of albedo when the temperature is close to melting in ACCESS1.5 (its in the atmospheric part of the UM7.3 code). In CICE5.1.2 there are two schemes, we use the UK one from CPOM in Reading there is an NCAR one as well.

The complication there is the melt pond information needs to be then passed back through the coupler back to the UM so the atmospheric model can do the albedo calculation (it duplicates code that sits in the ice model) and then passed to the UM radiation code, that set up is not available to us in UM7.3 it came in GA6 not sure which version of UM that was Martin (it was 2015 timeframe), but in our code base that we still maintain with that in was UM10.6, so it’s not going to work for what @LaurieM needs in the paleo runs.

So Unfortunately the answer is no there is nor advantage in upgrading to CICE5.1.2.

Siobhan

2 Likes
10

HI @RachelLaw The bug fix that we should fix that also impacts on diagnostics is the OASIS MCT set up which was a test one that went into ACCESS1-4, @dhb599 updated it and corrected the bug for ACCESS-CM2 but that sits inside the CICE5.1.2 model, as OASIS_MCT links across to the ice-ocean combined.
The advantage of this is we can then do the time derivative ice statistics, there may be some for the land and ocean and BGC time derivative statistics that were impacted in ESM1.5 by this coupler bug as well that we could use if its fixed.

Also we need to set up the “CMIP6” ice statistics internally in the CICE4.1 code, which will improve the quality of diagnostics over what we could obtain through the post-processing APP4 output. We will use CICE6.4/5 as our framework for this rather than the CM2 code as there were some bugs that came through from a “Beta” GSI8.1 of the CMIP6 output set up.

11

@sofarrell what is this bug? Is it and the fix documented somewhere?

12

Hi @dougiesquire I think we may have made a one line mention of it in Tilo’s paper on the model. It basically took 2 atmospheric time steps before it did a coupling time step to the ocean right at the start, Thats why it messes up the d/dt type statistics. (In Jan and July as we did 6 month chunks). No it hasn’t been documented. Even worse the comments in the code match the earlier ACCESS1-3 coupling set up. So don’t even go and look at you will get very very confused.

Dave totally re-wrote that section of code for ACCESS-CM2 and thats what we need to replace into this code for ESM1.6. We were too hard pressed doing two model versions back in “CMIP6” timeframe, to put into ACESSS ESM1.5 and only realised about the diagnostics too late.

It’s not a simple translation CM2 has code for CICE5.1.2 (our version is actually GSI8.1 from the Met office with local #ifdef changes) and ESM1.5 (ESM1.6) is CICE4.1 (The coupling code passes through CICE across for all ice/ocean grid points; unlike what is being done with the mediator and NUOPC).

1 Like
13

Many of the land improvements since ESM1.5 are automatically available as part of the CABLE3 codebase (notably for water and energy balance improvements). Land centric improvements that were developed as part of CABLE-CM2 that should (ideally) be back-ported (and would need code changes):

  • revisions to the meteorological forcing used in the ‘implicit’ section
  • lake water/inland water basins/river runoff fix (if technically possible)
  • CABLE specific modifications to MOSES routine im_sf_pt2 that addresses the energy balance of coastal grid cells.
  • Changes to the CABLE-MOSES interface code that facilitate a broader range of diagnostic outputs (e.g. sublimation, soil evaporation and transpiration partitioning) as requested by the community/CMIP.

Discussions around adopting the CM2 Antarctic/Greenland run off and iceberg scheme in ESM1.6 have also commenced (requiring code changes in CABLE, MOM5, CICE and the OASIS).

We should also review the sequence of the calling point to CABLE in the explicit and implicit sections (they weren’t optimal in CM2) and the MOSES science options invoked by CABLE (some of these are not compatible with CABLE science).

Land science that could be assessed as part of a ESM1.6 calibration exercise include:

  • updates to PFT parameters
  • use of litter layer and/or Or soil evaporation model
  • use of Medlyn stomatal function
  • use PFT-dependent root distributions
  • use of the updated (pitot) functions which link thermal and hydraulic parameter values to the soil texture and composition.
  • use of revised soil and other land ancillaries
14

Freshwater input to ocean from Antarctica/Greenland

This is treated differently in ESM1.5 and CM2. In ESM1.5, the snow depth is capped and any excess snow goes into runoff, gets routed to the coast and is input to the ocean at coastal grid points. In CM2, there is no cap. Required freshwater (for conservation) is calculated as a climatological seasonal cycle from the control simulation and applied to all other simulations. The freshwater is added to the ocean across a spatial area which is intended to represent where icebergs would add fresh water by melting.

We need to check

  • how much the amount of freshwater added to the ocean differs across the two methods
  • the impact from where the freshwater is added

We know that Antarctic Bottom Water Formation in ESM1.5 is about half that in CM2 in the control run (5 vs 10 Sv) so it would be good to understand whether the freshwater input is impacting this.

@RachelLaw to look at Antarctic runoff from existing runs.
@dhb599 to look at code that would need to be replicated in ESM1.5 from CM2.
@MartinDix , @inh599 noted that max_glacier_snowd and nglacier (0 or 2) are controlling runoff behaviour over snow in cable_soilsnow/cbl_surfbv.

15

Nitrogen flux units might want to be made more consistent. It seems as though N deposition is input/output as gN/m2/day while N fixing is input/output as gN/m2/y. The code accounts for this difference but it is more confusing than it needs to be. For CABLE standalone N deposition units appear to be gN/m2/y.

16

Hello all,
In terms of diagnostics, it would be good to have the annual mean total carbon content in different reservoirs (ie ocean, soil, vegetation…). I don’t know if it is already a variable in CABLE but so far we have not found it.
Thanks

17

Hi @LaurieM, carbon pools can be output as instantaneous end of month values on tiles. If the output has been converted to netcdf using archiver, they will be fld_s03i851 to fld_s03i860. See a list put together by @tammasloughran here for all the ACCESS archiver ‘Unknown variables’ : um2nc - fix for UNKNOWN VARIABLE · Issue #2 · ACCESS-Community-Hub/ACCESS-Archiver (github.com)

If summing to get total carbon, both tile fraction and land fraction need to be accounted for. Some combined pools are available cmorised e.g. cveg.

18

I should add

  • recent (AM3 era) revisions to account for different densities of ice and liquid water in soil hydrology - and the associated energy/water conservation fixes (especially due to dtmlt) - should make their way into ESM1.6.
  • testing around the 3-layer snow model (snmin parameter)
  • testing around the frozen_limit

Some data retractions occurred because of an error in the post-processing script (conversion from CABLE 6-layers to CMOR layers) that need to be followed up.

There is also a post in the land section of the hive attempting to collate additional land metrics which would be useful to have access to - see 3/1781. Some - but not all - of these could be enabled in a UM7.3 era model.

19

Additional input on rivers from @inh599

A quick follow up on the issues of rivers in ESM1.6 – good news and bad news.

In CM2/AM3 CABLE interacts with the JULES-rivers scheme by

  1. accumulating water added to lakes to keep them saturated
  2. accumulating water lost to inland river basins
  3. rescaling river outflow to oceans (globally) to account for the net imbalance.

In ESM1.5 CABLE interacts with the MOSES-rivers scheme by

  1. accumulating water added to lakes to keep them saturated (globally)
  2. accumulating water into rivers by summing runoff terms (globally)
  3. rescaling river inflow (globally) to account for the imbalance from 1.

In effect ESM has effect 1 but not 2 (and 2. almost balances 1 in CM2). Neither approach conserves water locally, the CM2 approach conserves water globally.

good news – conceptually the CM2/AM3 science can apply in ESM1.6. The routines are broadly the same and much of the necessary variable plumbing is already in place.

bad news – there are enough technical differences between the ESM1.5 and CM2/AM3 code that this would be non-trivial to do (in essence it’s a new design and implementation within MOSES-era code). A second issue is that the ESM1.5 code already includes its own rivers fix and so we will have to unpick this first*.

How critical is it that ocean volume is “steady” in ESM1.6? This may determine how important this activity is.

Ian

*CABLE3 in the ESM1.x code base may actually be passing the wrong information around to MOSES-rivers – so either way this needs further attention.