CABLE in AM3 development notes

Land Surface
1

This topic is to collate meeting notes around the ongoing development of ACCESS-AM3 with a focus on role of CABLE.

Key individuals: @clairecarouge @MartinDix @ben @Jhan @inh599

2

Meeting 16/1/2025

Status of developments:

  • AM3 is functional, proto-type AM3 codebase and suite has been shared with university colleagues.
  • CASA has been run using the AM3 codebase but output has not been assessed in anyway.
  • energy/water balance is reasonable (commensurate with CM2), still some energy imbalance over snow regions which could be followed up on at a later date.
  • progress to back port recent AM3 changes back into CABLE3-MAIN and ESM1.6 have resulted in a range of other concerns/technical challenges.
  • dust in proto-type AM3 is too low - attempts to rectify via changing (increasing) CABLE’s soil roughness have led to model instability (temperature oscillations). Work underway to identify and if possible resolve
  • request has been made for CABLE related ancillaries for AM3 at N216/N512 resolution and/or ANTS suite to create these.
  • restart reproducibility is commensurate with CM2 - known causes exist (%fes_cor being the key and necessary example) so this is not fully resolvable.

Additional open topics:

  • Process around release of AM3, including what documentation (science and ‘how to run’) is needed and possible.
  • CMORIsation of outputs.
  • Establishment of CABLE library

Other notes:

  • We will need to update the CASA codebase in AM3 to align with CABLE3 (there have been updates to sync ESM1.6 and CABLE3 that have occurred since AM3 branched off).
  • Suspected that the model instability/crashes relate to an odd combination of vegetation parameter values (very low LAI, high vegetation height) - points towards the need to update these ancillaries and/or enforce consistency between them inside the code [but care is needed around intersection with CASA]

To do:

  • @MartinDix To confirm exactly how the updated roughness length was implemented (there are two locations needed, likely only one was done)
  • @MartinDix @inh599 To look more closely at period of crash to see if we can confirm (narrow down) cause.
  • NRI - @ben @clairecarouge with input from @jhan - to lead design and development of workflow around the CABLE library (offline, ESM1.6 and AM3 separately first, but JAC should be also be remembered).
  • All: Review and tidy-up outstanding issues.

Next meeting: we will continue with fortnightly meetings for the moment (i.e. 30th January), but may relax to less frequently given focus on ESM1.6.

3

I am loathe to add an issue when I am trying to get rid of them BUT if this is deemed as an (reproducibility) important part of AM3 then I will add it to the STASH. My hesitation is that this alone will not give us reproducibility?

4

@Jhan It maybe better to go through the effort of adding this to STASH/restart (though whether to do that for AM3 only or both is a different question). Remember this %fes_cor issue is only a small effect acting on the first time step of each restart. I can’t guarantee that this is the only cause of the current failure of restart reproducibility, but was noting that this particular cause is known.

I’m still hoping that we can find time to rethink/assess the whole correction terms topic and see if we can find a way past them (without breaking conservation). This would simplify the syncing between offline and coupled, conceivably allow us to investigate the use of SLI, and/or allow for our soil&snow time stepping to moved out from implicit into extras (to align better with JULES).