209 new build

[anton-seaice]

Draft of new versions for ACCESS-NRI/access-om3-configs#390

[anton-seaice]

@chrisb13 - we can add the MOM version to this branch too. It doesn't build yet. There is some more to chase down in CESM_share still

(It gives this mysterious error:

 >> 547    /g/data/tm70/as2285/spack0.22/environments/x/access-om3-nuopc/share/CESM_share/src/shr_reprosum_mod.F90:453: undefined reference to `t_barrierf_'
     548    share/libOM3_share.a(shr_reprosum_mod.F90.o): In function `shr_reprosum_mod_mp_shr_reprosum_calc_':
  >> 549    /g/data/tm70/as2285/spack0.22/environments/x/access-om3-nuopc/share/CESM_share/src/shr_reprosum_mod.F90:453: undefined reference to `t_barrierf_'
     550    share/libOM3_share.a(shr_reprosum_mod.F90.o): In function `shr_reprosum_mod_mp_shr_reprosum_calc_':
  >> 551    /g/data/tm70/as2285/spack0.22/environments/x/access-om3-nuopc/share/CESM_share/src/shr_reprosum_mod.F90:453: undefined reference to `t_barrierf_'

)

[anton-seaice]

If ESCOMP/CESM_share#58 gets merged we can remove the #ifdef TIMING patch again.

[anton-seaice]

If ESCOMP/WW3#33 gets merged we can remove the ifdef W3_IC4 patch too

[anton-seaice]

I also asked about the wrong variable name in CDEPS here

I moved a newer CDEPS because it's sets a default value for a namelist parameter we don't set, (ESCOMP/CDEPS#315)

[anton-seaice]

@aekiss @chrisb13

This is basically ready for review. This change implements new component versions for the model components as follows:

• MOM6, using an up to date MOM-ocean version + the generic tracers changes. Access-nri version 2025.01.0
• CICE, using CICE6.6.0, plus local changes for MOM supergrid implementation and to fix cice history filenames per https://github.com/COSIMA/access-om3/issues/190#issuecomment-2261753828. Once Make datestamps in pointer filenames configurable ACCESS-NRI/CICE#9 is resolved I will do a release tag.
• WW3, dev/unified_0.0.12 from CESM plus a local patch to fix a minor implementation issue with the "IC4_NUMERICS" fix
• CDEPS 1.0.59 from CESM
• CMEPS 1.0.25 from CESM
• CESM_share 1.1.5 from CESM

See individual commits for minor implementation details.

See pre-release deployment:

ACCESS-NRI/ACCESS-OM3#33

and

Draft config update:

ACCESS-NRI/access-om3-configs#154 (comment)

[access-hive-bot]

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

https://forum.access-hive.org.au/t/cosima-twg-announce/401/54

[access-hive-bot]

This pull request 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-2025/4067/2

[aekiss]

LGTM on a quick look, but I'm too far removed from the nitty-gritty to pick much up. Maybe @dougiesquire could have a look if he's back?

[chrisb13]

LGTM too, although I'm most familiar with the MOM changes. Small things...

To be clear, I've understood this PR to involve these 3 sets of changes (22 commits), plus model component updates, which would all be accepted/merged at once (correct?):

• main...209-new-build
• ACCESS-NRI/ACCESS-OM3@main...209-new-cosima-build-2
• ACCESS-NRI/access-om3-configs@dev-1deg_jra55do_ryf...209-dev-1deg_jra55do_ryf

On a practical point, once everything is merged (assuming you'll do the default GH 'create merge commit'), it's not clear to me how this reference to 209-new-build will work? @micaeljtoliveira tells me the branch name will remain where it is now but the CI may choose to work off the merge commit, which in some cases could be problematic. I see how it's convenient to reference a branch when testing an evolving build but I think now that it's at a release it is safest for this to be changed to a tagged commit. I also think a tagged commit should be used for CICE (perhaps a preliminary one whilst you're awaiting resolution on this).

What is the reason for this failing? I note that the repro check actually uses pr33-12 (not the failing pr33-14). (Although, the symmetric option has been tested elsewhere.) In general, can we please write a brief status when running CI commands such that there's a record of what's changed/why it's being run.

Since @dougiesquire is back on Monday, perhaps we should ask him to have a quick look too?

[anton-seaice]

LGTM too, although I'm most familiar with the MOM changes. Small things...

To be clear, I've understood this PR to involve these 3 sets of changes (22 commits), plus model component updates, which would all be accepted/merged at once (correct?):

* [main...209-new-build](https://github.com/COSIMA/access-om3/compare/main...209-new-build)

* [ACCESS-NRI/ACCESS-OM3@main...209-new-cosima-build-2](https://github.com/ACCESS-NRI/ACCESS-OM3/compare/main...209-new-cosima-build-2)

* [ACCESS-NRI/access-om3-configs@dev-1deg_jra55do_ryf...209-dev-1deg_jra55do_ryf](https://github.com/ACCESS-NRI/access-om3-configs/compare/dev-1deg_jra55do_ryf...209-dev-1deg_jra55do_ryf)

Sort of. This PR merges the first one, which i've tried to work into 6 neat commits. The other two are related, but need further updates which are dependent on this update. And then get their own PRs. And another 4 ish PRs for the other config branches in om3-configs.

On a practical point, once everything is merged (assuming you'll do the default GH 'create merge commit'), it's not clear to me how this reference to 209-new-build will work? ...

Yes 209-new-build gets deleted. Ill will do a "release" in this repository, creating an 0.4.0 tag. The 0.4.0 tag then gets used for the deployment repo.

I also think a tagged commit should be used for CICE (perhaps a preliminary one whilst you're awaiting resolution on this).

Ah yep. Ill merge the CICE PR first and update the commit in this PR.

What is the reason for this failing? I note that the repro check actually uses pr33-12 (not the failing pr33-14). (Although, the symmetric option has been tested elsewhere.) In general, can we please write a brief status when running CI commands such that there's a record of what's changed/why it's being run.

I think the PR is marked as failing because the most recent commit triggered build failed. pr33-12 and pr33-14 (the latest one) both passed. I am not sure what happened in between!

Since @dougiesquire is back on Monday, perhaps we should ask him to have a quick look too?

Okie

[chrisb13]

@anton-seaice. Thanks for clarifying, sounds good.

Yes 209-new-build gets deleted. Ill will do a "release" in this repository, creating an 0.4.0 tag. The 0.4.0 tag then gets used for the deployment repo.

Ok, let's have a chat about this next week. Would be good to make sure we're on the same page -- to my mind, the safest option is to make the tag before the merge (is that what you mean?).

[anton-seaice]

At the team meeting today - we decided to use patches for MOM6 in this release instead of a commit from a branch.

I've changed MOM6 to pull the latest commit from MOM-ocean, and reverted the patches. The build fails now and I assume that @dougiesquire and or @chrisb13 will fix the patch files in the MOM6/patches folder

patching file /home/runner/work/access-om3/access-om3/build/MOM6/mom_ocean_model_nuopc.F90 (read from /__w/access-om3/access-om3/MOM6/MOM6/config_src/drivers/nuopc_cap/mom_ocean_model_nuopc.F90)
Hunk ACCESS-NRI/access-om3-configs#228 succeeded at 20 (offset 1 line).
Hunk ACCESS-NRI/access-om3-cosima#4 succeeded at 406 with fuzz 2 (offset -3 lines).
Hunk ACCESS-NRI/access-om3-cosima#5 succeeded at 521 (offset -3 lines).
Hunk #6 succeeded at 783 (offset -3 lines).
Hunk #7 succeeded at 814 (offset -4 lines).
Hunk #8 succeeded at 831 (offset -4 lines).
Hunk #9 succeeded at 889 (offset -4 lines).
[ 17%] Generating MOM_PointAccel.F90
cd /home/runner/work/access-om3/access-om3/build/MOM6 && /opt/software/linux-ubuntu22.04-x86_64_v3/gcc-11.4.0/cmake-3.24.4-34wqgj6f7jw36cqkvx2nmirahpjzpj65/bin/cmake -Din_file:FILEPATH=/__w/access-om3/access-om3/MOM6/MOM6/src/diagnostics/MOM_PointAccel.F90 -Dpatch_file:FILEPATH=/__w/access-om3/access-om3/MOM6/patches/MOM_PointAccel.F90.patch -Dout_file:FILEPATH=/home/runner/work/access-om3/access-om3/build/MOM6/MOM_PointAccel.F90 -P /__w/access-om3/access-om3/cmake/PatchFile.cmake
'/usr/bin/patch' '/__w/access-om3/access-om3/MOM6/MOM6/src/diagnostics/MOM_PointAccel.F90' '--input=/__w/access-om3/access-om3/MOM6/patches/MOM_PointAccel.F90.patch' '--output=/home/runner/work/access-om3/access-om3/build/MOM6/MOM_PointAccel.F90' '--ignore-whitespace'
patching file /home/runner/work/access-om3/access-om3/build/MOM6/MOM_PointAccel.F90 (read from /__w/access-om3/access-om3/MOM6/MOM6/src/diagnostics/MOM_PointAccel.F90)
Hunk ACCESS-NRI/access-om3-configs#228 FAILED at 122.
Hunk ACCESS-NRI/access-om3-configs#229 FAILED at 461.
2 out of 2 hunks FAILED -- saving rejects to file /home/runner/work/access-om3/access-om3/build/MOM6/MOM_PointAccel.F90.rej
CMake Error at /__w/access-om3/access-om3/cmake/PatchFile.cmake:29 (message):
  Failed to apply patch
  /__w/access-om3/access-om3/MOM6/patches/MOM_PointAccel.F90.patch to
  /__w/access-om3/access-om3/MOM6/MOM6/src/diagnostics/MOM_PointAccel.F90
  with /usr/bin/patch

[anton-seaice]

It offers me a delete option for the 2025.01.0 Pre-release here of MOM6. Shall I do that?

[dougiesquire]

It offers me a delete option for the 2025.01.0 Pre-release here of MOM6. Shall I do that?

Probably yes, but maybe worth holding off until we have a working alternative

[dougiesquire]

Okay, okay, I'll get this working locally first 😑...

[dougiesquire]

I've redone the patch files for the recent MOM update (now up to date with current mom-ocean/MOM6:main). The MOM6 test suite now passes with these patches applied (bearing in mind that MOM_couplertype_infra.F90.patch needs to be applied to both config_src/infra/FMS1 and config_src/infra/FMS2 for the tests) - see this branch of our MOM6 fork with the patches enabling generic tracers applied.

xref ACCESS-NRI/MOM6#5

[dougiesquire]

Thanks @anton-seaice et al - looks great! One question, one suggestion.

[anton-seaice]

Build with todays review changes (redeploy 16):

ACCESS-NRI/ACCESS-OM3#33 (comment)

and the test with MOM6-CICE6:

ACCESS-NRI/access-om3-configs#154 (comment)

I also ran an adhoc test with MOM6-CICE6-WW3 which worked with removal of DEFAULT_2018_ANSWERS = False from MOM_input

[anton-seaice]

Ill double check on Tuesday and then merge :-)