Update components for v0.4.0

[dougiesquire]

This issue is to plan and track the progress of updating the OM3 components to newer versions.

As part of this, I'd like to propose moving to our own forks of MOM6, CICE6 and CDEPS.

So here is a first attempt at the list of tasks:

• Create ACCESS-NRI forks of MOM6 and CDEPS. We already have an ACCESS-NRI CICE fork (of ESCOMP/CICE) and CMEPS fork.
  • See MOM6 and CDEPS
  • The fork management plans are in the MOM6 wiki and CDEPS README (we don't want to add commits to the MOM6 default branch that aren't candidates for a PR back to mom-ocean/MOM6:main)
• Do we want our own fork of WW3?
• Update the Spack environments in /g/data/ik11
• Decide on which versions we want to update to
• Transfer patches/extra_sources into newly forked repos (where appropriate)
  • CDEPS
  • CMEPS?
  • MOM6 (might need to push this to a later release when I'm back from leave?)
  • CICE?
  • WW3?
• Update versions in the OM3 codebase
• Update the configurations as needed
• Do a release of OM3

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2024/1734/16

[anton-seaice]

  * We will need to decide which repos we fork and come up with a management plan for our forks

https://github.com/ciCE-Consortium/cice uses squash commits. I don't think there is a model to have ACCESS specific commits and update from the cice main branch which doesn't involved re-applying the commits on top of the cice main. e.g.

• If you branch from cice main, and then apply some commits, then merge the access commits into cice main and then try and update the access fork, you will have the commits applied plus the squashed commit from PR into cice main ? I think this is what NOAA do
• If you rebase your local fork from cice main instead, then every so often you will have to rewrite the history of the local fork. I think this is what CESM do. The problem with this model is it is hard to follow the history of main (i.e. its not on the commits anymore and not linear!) To avoid rewriting main I guess we could make a new branch everytime we update from upstream.

Anyway, no good suggestions from me on how to handle this !

[anton-seaice]

Also I would like it if we document the process to update versions - see #146

[anton-seaice]

Extra also, has there been any discussion on using OpenMPI 5.x.x instead of OpenMPI 4.x.x ?

[dougiesquire]

• If you rebase your local fork from cice main instead, then every so often you will have to rewrite the history of the local fork. I think this is what CESM do. The problem with this model is it is hard to follow the history of main (i.e. its not on the commits anymore and not linear!) To avoid rewriting main I guess we could make a new branch everytime we update from upstream.

We definitely do not want to be rewriting history of "public" branches

[dougiesquire]

Extra also, has there been any discussion on using OpenMPI 5.x.x instead of OpenMPI 4.x.x ?

Not that I know of

[anton-seaice]

I think the fix for parallel reads through symlinks on lustre has been done in 5.x.x (open-mpi/ompi#12141)

[dougiesquire]

I think the fix for parallel reads through symlinks on lustre has been done in 5.x.x (open-mpi/ompi#12141)

Nice, we should test this