COSIMA TWG Meeting Minutes 2026

COSIMA TWG
, ,
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.