Update CM3 versions for MOM6, CMEPS, CDEPS, WW3, and share

[blimlim]

This pull request updates versions for MOM6, CMEPS, CDEPS, WW3 and CESM_share on the CM3 branch to bring them into line with the versions on main. We originally hopped to update just one component at a time, but dependent changes between components, library versions, and the Cmake files meant that I've ended up updating all these components at once.

The CMEPS version will be updated once the following PRs on our CMEPs fork are merged: ACCESS-NRI/CMEPS#4 and ACCESS-NRI/CMEPS#6, and so I've set this as a draft. I suspect there might also be changes required around a lot of the Cmake changes, which I'm not too experienced with.

This PR updates to versions:

• MOM6 -> 776be84
• Generic tracers -> 275ab7a
• CMEPS -> 1.0.25 (see related : Update to CMEPS 1.0.25 ACCESS-NRI/CMEPS#4)
• CDEPS -> 1.0.59 8197f05
• WW3 -> dev/unified_0.0.12 1c11fc1
• CESM_share -> 1.1.5 a48ff87

There have been several changes to the CmakeLists files in main since the cm3 branch split off. These include changes to the sources, and also changes to the way the libraries are named and organised. In each case, I tried to take the changes from main. For reviewers: the differences between these files and the versions in main are shown here

The main branch also updated several library and module versions:

• esmf8.4.2 -> esmf/8.5.0
• fms/2021.03.01 -> fms/2023.02
• parallelio/2.5.10 -> parallelio/2.6.2
• intel-compiler/2021.6.0 -> intel-compiler/2021.10.0
• openmpi/4.1.4 -> openmpi/4.1.5
• Fortranxml is no longer built here, and loaded via fortranxml/4.1.2

These new versions will need to be added to the cm3-suite.

These changes break CM3 bit reproducibility. I'll include a comparison on flux conservation and water balance before and after the changes.

[blimlim]

The gcc compilation fails due to character arrays with different entries in esmFldsExchange_access_mod.F90, e.g:

      S_flds = (/'Sa_pslv', & ! inst_zonal_wind_height10m
                  'So_duu10n' /) ! inst_temp_height_surface

Apparently intel compilers let this through, but gfortran doesn't allow it, which is why building manually on Gadi has worked so far.

[anton-seaice]

Hi @blimlim

I think it might be easier to manage this by making a new branch from rebasing the cm3 branch onto main (or an equivalent approach would be to start with a fresh branch of main, and then cherry-picking each commit from the cm3 branch).

And then build using spack (use the CI) with +install_libraries turned on. This means all your versions will be up to date and divorced of any cosima spack stuff. Then we can just point to the modules deployed in 'vk83' in the build script until there is a spack package for CM3. You might need to update your CICE version at the same time, depending on how dependencies have changed.

[blimlim]

Thanks @anton. The approach was to do the updates step wise, starting with just MOM, and then updating CICE in a separate PR, checking what has changed in the simulations at each step. Once the versions were in line with main, we'd then merge in from main.

Would it still be possible to do this starting from main? One reason we wanted to do it this way is that we have much more changes in the CICE code, and so that step may be much more involved

[blimlim]

Oh, I guess I could do that but just not update CICE. I'll try it out

[anton-seaice]

I don't really think doing it piecewise is worth the effort - e.g. there's no way to know which result is correct after making the change. And in general there are too many changes where versions are not cross compatible to be confident in this approach.

Either way - start from the latest deps in ACCESS-NRI/ACCESS-OM3 and build up from there. I've kicked off a build with new deps and old code (see ACCESS-NRI/ACCESS-OM3#50) to see if it works.

Would it still be possible to do this starting from main? One reason we wanted to do it this way is that we have much more changes in the CICE code, and so that step may be much more involved

I think just drop the commit which updates CICE in the new cm3 branch and see !

[anton-seaice]

This looks like a promising start - ACCESS-NRI/ACCESS-OM3#50 (comment) :-)