COSIMA TWG Meeting Minutes 2026

COSIMA TWG
, ,
1

Date: 14 Jan 2026

Attendees: @sofarrell, @AndyHoggANU, @aekiss, @kieranricardo, @MartinDix, @helen, @NoahDay, @anton, @ashjbarnes, @dougiesquire
Chair: @cbull
Minutes: @minghangli

1. Regional Ocean Model Automation Planning - Regional MOM6 Stencil · Issue #1044 · ACCESS-NRI/access-om3-configs · GitHub

@ashjbarnes’s role and scope

Current goal is to make rOM3 ocean model setup faster and to support regional coupling (rOM3 + rAM3). @ashjbarnes has just started, is currently based in Canberra working on automating the setup of regional ocean model domains, and plans to move to Tasmania later to focus on coupling rOM3 and rAM3.

Stencils concepts and long-term plan

A long term plan is forming around stencils (template configurations) that users can download and then have the tooling rewrite paths/files to match a specific regional domain setup. The intent is that multiple stencils will exist over time, starting with a rMOM6 stencil and later expanding to additional templates, including a WOMBAT stencil aligned with prior work.

Regional MOM6 vs ACCESS-NRI configs

Current regional MOM6 copies default configuration files, such as MOM_input, config.yaml etc, and hard coded for a default FMS run. The proprosal is to shift rOM3 relevant defaults to ACCESS-NRI configuration repos, so regional MOM6 inherits from those maintained configs.

An alternative way is to keep rMOM6 doing the heavy lifting, such as regridding etc, while a thin ACCESS-NRI wrapper repo handles only configuration manipulation. But this would split the workflow across repos which is less desirable for users.

Constraints

A practical constraint discussed: putting content in ACCESS-NRI org repos enables internal testing (and potentially running tests on Gadi). Collaborators can still contribute via PRs but direct pushing to main is restricted.

Another discussion was on whether stencils are just one-off templates or they must be kept up-to-date alongside evolving supported configs. A likely outcome is a hybrid:

  • Some components must stay aligned with global/supported setups.
  • Other parts will diverge for regional needs, such as parameter choices and other specific tuning work.

Others

Some disagreement on MOM_input vs MOM_override:

  • keep regional changed in a maintainable way via MOM_override, easier to track changes
  • keep a regional MOM_input and potentially multiple selectable variants, similar to how diag_table are handled, because regional configs are inherently perturbations relative to global defaults.

Workflow discussion - generate from scratch or subset from global config

  • Generate regional grids/topog from scratch from defining corner points/region definition.
  • Subset from an existing global parent grid, keeping exact alignment with a global config (Claire’s needs).

2. OM2 25km config issues and testing updates

Restart reproducibility in released 25km configs

All released 25km ACCESS-OM2 configs are currently not restart reproducible. The issue is now resolved and can be found in 0.25deg configurations are not restart reproducible · Issue #245 · ACCESS-NRI/access-om2-configs · GitHub

25km IAF configuration instability after exe updates

The most recent 25km IAF release crashes after ~9months, debugging work will start since the restart repro issue is fixed now.

Restart repo testing was not routinely run for these configs (scheduled tests). PR testing has been updated and scheduled testing will be updated once the underlying issue is fixed.

3. WOMBAT status and release framing

25km WOMBAT-lite run results

A 25km WOMBAT-lite RYF run kicked off before Christmas and output looks good. Pierce has been reviewing. Hence this is likely sufficient to demonstrate progress and tick prior milestones, especially since the milestone was framed as 2025-era.

RYF vs IAF for WOMBAT-lite

No strong preference; switching between RYF/IAF is mostly forcing file selection and could be done quickly. For stakeholders, “it runs and looks reasonable” is likely enough.

CM3 priorities

WOMBAT is not a high CM3 priority right now. The WOMBAT update is primarily about demonstrating progress rather than immediate integration demand.

4. OM3 upstream updates

A conflict with an existing patch in CDEPS is seen as a chance to move away from patching toward using maintained forks. Current plan includes having contributors to commit their work so history/authorship is preserved.

5. Iceberg spreading discussion

details:

Adapt CM3 river spreading for OM3 iceberg spreading

An idea is raised to reuse the existing mass-conserving exponential smoothing used for river spreading in CM3 and apply it to iceberg spreading in OM3. This would keep most flux near the coast while spreading it outward smoothly - potentially reducing extreme local build up.

Thickness spikes and total volume bias

Currently OM3 has some extreme points exceeding 10km thickness! CM3 avoids extreme spikes by distributing more evenly, but still has a total ice volume bias.

Latent heat extraction

There’s another discussion about latent heat extraction when runoff/iceberg flux enters the ocean. A possible way is to split snowfall/runoff 50/50 frozen vs liquid so latent heat is not extracted for the entire volume.

Likely causes

We need to fix the core issues first - polar landmask / non-advective cells before relying on engineering fixes, while still keeping spreading improvements as an option.

A note was mentioned that NASA ran similar processing and didn’t see the same issues, so the land mask differences might be a key factor?

1 Like
COSIMA TWG Announce
ACCESS-OM3 development highlights/updates
2

Great summary @minghangli ! Just tagging @PSpence and @mmr0 to keep them in the loop of the rOM3 discussion

1 Like
3

Thanks @ashjbarnes. If we can, would prefer to keep this thread to minutes. But @PSpence and @mmr0 feel free to chime in on rOM3 things here.

4

Date: 28 January 2026
Chair: @cbull
Minutes: @ezhilsabareesh8
Attendees: @anton, @aekiss, @AndyHoggANU, @cbull, @ezhilsabareesh8, @helen, @angus-g

MOM Consortium Meeting Update (Dougie)

  • MOM6 proposed license change to Apache 2.0, requiring agreement from all contributors historically.
  • Round‑the‑room updates from centres included ongoing GPU work and other development topics, none requiring urgent action for ACCESS‑NRI.
  • Regarding next MOM6 PR window:
    • A PR call has been issued by Bob.
    • Dougie suggested ACCESS‑NRI may delay submitting until the new BGC‑coupling alignment working group progresses, as planned changes may affect how ACCESS‑NRI handles BGC interfaces.
    • GFDL may contribute CMIP diagnostic improvements in the meantime.
    • Plan: Reassess in a few weeks which group (ACCESS or GFDL) should submit first.

Community Contributions & Upstreaming Discussions

  • Chris raised whether ACCESS‑NRI should put out a community call to clarify which external contributions might be ready for upstreaming.
  • Dougie emphasised:
    • PRs to MOM6 must come from code that is already in ACCESS‑NRI default branches.
    • Minor bug fixes could be bundled into a future larger PR.
    • Larger contributions (like Angus’s) are close to being PR‑ready.
  • Timeline for upstream PRs is not fixed; contributors decide when their changes are ready.
  • Rebased contributions generally manageable; rebasing is already a routine part of MOM6 updates.

Ice Shelf & Offline MOM6

  • Ice shelf development remains primarily within ACCESS‑NRI, with limited activity elsewhere.
  • The offline MOM6 received brief mention; potential future support remains unclear.

GM Parameterisation Recommendations (Andy)

  • Multiple GM configurations were tested (GM1–GM5).
  • The original 1.0‑beta case had overly strong GM coefficients (~600 m²/s), especially in the Southern Ocean, which excessively damps eddies.

GM4 Case – Recommended for Next ACCESS‑OM3 Release

Run:

GM4 parameter changes:

Parameter GM4 Value
MEKE_KHTH_FAC 0.3
MEKE_KHTR_FAC 0.3
MEKE_VISCOSITY_COEFF_KU 0.6
  • GM magnitudes in GM4 match ACCESS‑OM2 (~200 m²/s peaks, zonal means <100 m²/s).
  • Southern Ocean behaviour is significantly improved:
    • Upwelling stays on consistent density surfaces, instead of crossing densities as in the baseline.
    • ACC transport falls within observed constraints.
  • No degradation seen in other major diagnostics.

Remaining Issues:

  • Western boundary current separation biases persist for the Kuroshio and Gulf Stream.
  • GM5 (with backscatter) did not remedy these biases; alternative approaches needed.

Actions:

  • Andy to create an issue in access‑om3‑configs documenting:
    • GM4 parameter updates and impacts

Wombat BGC Status (Dougie)

  • Initial concerns about tracer drift (especially nitrate) were resolved after WOMBAT update and longer runs; apparent drift plateaued after masking artefacts were removed.
  • Wombat is considered ready for release.
  • OM2 release will occur first, then OM3. Long evaluation runs at multiple resolutions are available.

Pan‑Antarctic (PanAn) Configuration Stability (Dougie)

  • The PanAn (no ice shelves) configuration shows 20–30% startup failure rate.
  • Can run reliably by restricting lower-level MPI libraries and removing runoff remapping.
  • Cause of issue is unclear. Dougie not convinced it isn’t related to an issue with input files.
  • Angus has had similar failures using MOM6 solo builds.
  • Neither Dougie or Angus have tested the performance cost of setting MPI flags, though anecdotally there isn’t an obvious difference.
  • With OpenMPI 5, the configuration either crashes or hangs indefinitely
  • Agreed to proceed with the stable configuration using MPI flags for the alpha release.

CM3 Evaluation notebooks

  • Ezhil is updating OM3 notebooks to be CM3‑compatible.
  • Advised coordinating with the MED team to avoid duplicated effort

Next Steps for Full IAF Cycle

  • Discussion on whether to include Wombat in the next full IAF configuration spin‑up.
  • Benefits noted for joint physics‑biogeochemistry evaluation; community members could help assess additional outputs.
COSIMA Working Group Announce
5

Date: 11 Feb 2026

Attendees: @sofarrell, @AndyHoggANU, @aekiss, @kieranricardo, @anton, @dougiesquire, @Paul.Gregory
Chair: @cbull
Minutes: @minghangli

1. Data comparison and early evaluations

  • @AndyHoggANU aims to compare OM3, CM3, OM2 at 8km and 25km using available data in the datastore.
  • @kieranricardo suggested salinity and wind stress look improved after a fix (reference for this fix??). Adding iceberg flux increased sea ice, which is helpful in some regions but may worsen already-high northern hemisphere total sea ice and it is too high. Ice now appears around Greenland.
  • Some concerns are deferred until the B-grid landmask is available. Until then, avoid overinterpreting artefacts.

2. B grid landmask + topography workflow

  • @aekiss reported polar B-grid landmask/topography workflow is basically done but not fully tested.
  • Updated topo and mask files have been generated and staged in pre-release but not pushed to configs yet because further checks are still pending, such as restoring, marginal seas and other tweaks.
  • Changes are focused on coastal/marginal sea regions where any sea ice has occurred in long runs.
  • We agreed to finish validation test first then push to the iaf configs and likely run a new iaf cycle incorporating fixes. Start a fresh CM3 run once the new landmask is minimally tested.

3. MOM6 dev meeting updates

  • @dougiesquire made notes in #ocean-seaice > MOM6 dev calls @ :speech_balloon: and the update highlighted MOM6 move towards Apache 2.0 relicensing - all contributors have approved. This mainly makes code share into/out of MOM6 easier across models.
  • @dougiesquire showed what we do with Zenodo releases. Bob and Alistair seemed to like the approach.
  • @angus-g is expected to submit an adaptive grid PR at some stage (not urgent, paper is still needed)

4. 100km grid generation

  • @ezhilsabareesh8 raised questions on the ocean_model_grid_generator with the equitorial refinement. It produced sharp transitions and a completely different profile even though it fixed a north pole area spike and some bifold issues.
  • On the other hand, make_hgrid can reproduce what access-om2 used but introduces a tiny bifold asymmetry due to a rotate-pole area calculation (difference is very small).
  • We agreed the symmetry artefact is not a concern and it’s better to use the tool that produces the right functional form and overall behaviour.
  • One tweak is requested to move the start of the constant Y southern band from 78S to 75S to add a bit more resolution at those latitudes.

5. Render evalution figures

  • @cbull provide a quick figure first view for community members who want to contribute scientifically without running code.
  • @anton preferred hosting in the same repo as the recipes/notebooks and publish versions via tags so each tag builds a version of the site. This avoids PR overhead.
  • Some concerns:
    • Maintenance burden is the biggest risk - notebooks dont run out of the box and checking results is time-consuming.
    • Some clarity needed on if figures are snapshots or averages and what time windows were used.
    • Fully rendering notebooks is simpler but can be long. Summary pages are more usable but introduce extra curation steps.
  • It’s better to write down exact steps so effort can be compared directly.
  • Decide how to embed or standardise metadata such as averaging period or snapshot timing without relying on people membering to manually edit captions.

6. TWG reporting

  • @aekiss proposed replacing purely minute-based reporting with a short curated highlights update aimed at what the community actually cares about.
  • Keep minute-taking process the same but reporting can be owned by one person but open to contributions.
  • @aekiss will draft/drive the curated reporting approach and coordinate with the roster/minute-taker.

7. Next OM3 release status

  • There was concern that OM3 release work is already partially in progress but risks becoming stale due to upstream churn and @cbull has prioritised other work including Ocean Sciences travel with an approximate return around mid March.
  • The long gaps make the process harder because contexct is forgotten and upstream changes accumulate and we preferred smaller and more regular progress.
  • @anton suggested near-term risk reduction step is restart comparison or coupling sanity checks to catch obvious breakages like fields becoming zero. @cbull considers handing off parts of the release effort if not progressed before travel.
7

Date: 25 Feb 2026

Attendees: @sofarrell, @aekiss, @dougiesquire, @ezhilsabareesh8, @manodeep
Chair: @anton
Minutes: @minghangli

1. OM3 optimisation workflow handover update

2. Bottom roughness & processor layout update for 25km w & w/o wombat configs

3. OM2 updates

  • @dougiesquire shared 2 updates, first was driven by external users attempting to build ACCESS on other HPC systems, NeSi in NZ and archer2 in the UK. They had questions due to intel-compiler flags that are cpu restrictive such as AVX2-style flags. We are preparing PRs to replace these with alternatives suggested by @manodeep that are not cpu restrictive and they plan to test for performance impact.
  • second - OM2 can compile with GCC but not previously due to invalid memory issue. @dougiesquire tracked it down to issues in MOM5 and libaccessom2-related and has fixed it hence now OM2 compiled with GCC can run. The main problem was essentially uninitialised pointer issues that intel did not flag but GCC did.
  • A question about latent heat of vaporatisation constant used in FMS v.s. other components - UM and CICE5, where a previous change updated FMS and created inconsistencies. But this constant change could cause small answer changes in OM2. We agreed the component mismatch is a bug cuz inconsistency coefficients can lead to energy transfer inconsistency between components. Hence we prefer consistency across components. We ended up ensuring consistency is more important than a small constant change, which can be well documented / release notes.

4. Spack 0.22 → 1.1 transition

  • The upgrade helps as mostly positive - faster operation, bug fixes and less rebuilding (e.g. ESMF) and clearer versioning infra.
  • Currently OM3 updates appeared answer-changing, likely due to how Spack 1 applies architecture flags by default based on the target in spack.yaml. In 1.1, the default was x86-64-v4 rather than the baseline x86-64. By forcing x86-64, it appeared behaviour was restored closer to 0.22.

5. Bluelink workshop invite

  • @helen discussed an invite to present at the Bluelink workshop 24-25 March.
  • The slot was potentially agreed to a combined 30 minute slot, splitting global and regional updates.
  • Some updates in improved analysis, iaf runs and WW3-related results may interest the community.
  • The organiser only needs a title, one line description, duration by the following week.

6. Planning next 25km iaf run

@aekiss described preparing for the next 25km iaf run, including,

7. Kara strait salinity spike

For the 100km config, there’s an extreme surface salinity in the Kara Trait causing a crash due to out of range surface values. @ezhilsabareesh8 increased the threshold to keep the run going and aksed if salinity restoring in that region should be checked?

  • Suggestions like checkinig any available diagnostics for restoring tendencies but also noted that such extreme high salinity is more consistent with strong sea ice formation or a numerical instability than restoring alone.
  • Precipitation handling could also be a contributor - if precipitation/runoff is routed correctly into ocean and if runoff spreadings are appropriate in that region?
  • Kara sea river inflows typically freshen so the fact salinity is high argues against runoff directly causing it.

8. Restoring issue

  • We discussed the zero contour restoring behaviour and discussed if it has a meaningful impact on the global mean salinity cycle. The general view was that it likely does not affect the global mean but it may introduce small regional distortions, particularly near the boundary where the restoring tendency changes sign.
  • Even though the model develops, the zero net flux constraint was never revisited but just carried forward historically. So it is likely an inherited design choice rather than really thinking about it. The historical motivation was because of numerical stability and drift control, but it may not be physical ideal.
  • CESM may prioritise fully coupled configurations where such constraints are less relevant. And also some parameters may simply inherited from CESM defaults rather than being chosen for OM3.
  • So we decided to defer this to a future cycle instead of the upcoming run.
8

11 March

Pearse, Anton, Ezhil, Noah, Chris, Siobhan, Manodeep, Helen, Andrew K, Dougie

WOMBATlite performance - what to do about OM2 configurations?

Om3 doesn’t have this problem as it has the long tracer timestep

Dougie suggests Sapphire Rapids and increasing ocean core count - will plan to implement for all BGC configs.
Pearse suggests removing two DIC tracers

Pearse is planning at least one IAF cycle of 0.25 degree. And longer “spinups” with 1 degree
Then some targetted research using 0.1 degree and possibly do an updated control run with this.

WOMBATlite is fairly mature - ready for some memory / loop optimisation work

Global metrics

CICE consortium are having some preliminary discussions about a refactor of the history code. The question came up about whether to include hemispherical scalars

In OM2 - the global metrics was very slow to calculate. Therefore using snaphsots to reduce the number of global gathers.

We would use but probably not a great tool for science - medium priority

OM3 - Next deployment

For the IAF cycle this month - we need at least WOMBATlite updated
Access3-share - the coupler (CMEPS / CDEPS and share) components have been updated
CICE/WW3 yet to be updated, but possibly could be monday. ADDED by @dougiesquire: MOM6 has been updated (MOM6 2026.01.000).
Nice to have icemerg melt spreading but not essential - Anton to let Kieran know PR for this is ready

WW3 - ERA5 work is progressing well

ACCESS-OM2-025 + WOMBAT performance and scaling on Gadi