Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

209 new build #250

Merged
merged 6 commits into from
Jan 28, 2025
Merged

209 new build #250

merged 6 commits into from
Jan 28, 2025

Conversation

anton-seaice
Copy link
Contributor

Draft of new versions for #209

@anton-seaice
Copy link
Contributor Author

@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
Copy link
Contributor Author

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

@anton-seaice
Copy link
Contributor Author

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

@anton-seaice
Copy link
Contributor Author

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 anton-seaice force-pushed the 209-new-build branch 3 times, most recently from 660e4d6 to 038cc27 Compare December 13, 2024 02:59
@anton-seaice anton-seaice force-pushed the 209-new-build branch 2 times, most recently from 25ec99c to e47ee7c Compare December 20, 2024 00:57
MOM6/CMakeLists.txt Outdated Show resolved Hide resolved
@anton-seaice
Copy link
Contributor Author

@aekiss @chrisb13

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

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)

@anton-seaice anton-seaice requested a review from aekiss January 14, 2025 05:06
@anton-seaice anton-seaice marked this pull request as ready for review January 14, 2025 05:06
@access-hive-bot
Copy link

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
Copy link

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

Copy link
Contributor

@aekiss aekiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

@chrisb13 chrisb13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?):

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
Copy link
Contributor Author

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/[email protected]](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
Copy link
Contributor

@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
Copy link
Contributor Author

anton-seaice commented Jan 22, 2025

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 #1 succeeded at 20 (offset 1 line).
Hunk #4 succeeded at 406 with fuzz 2 (offset -3 lines).
Hunk #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 #1 FAILED at 122.
Hunk #2 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
Copy link
Contributor Author

anton-seaice commented Jan 22, 2025

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

@dougiesquire
Copy link
Collaborator

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
Copy link
Collaborator

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

@dougiesquire
Copy link
Collaborator

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

Copy link
Collaborator

@dougiesquire dougiesquire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

WW3/patches/w3srcemd.F90.patch Show resolved Hide resolved
share/CMakeLists.txt Outdated Show resolved Hide resolved
@anton-seaice
Copy link
Contributor Author

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

- update patch files for updated MOM6 version

- Add new modules to MOM CMakeLists

Co-authored-by: Dougie Squire <[email protected]>
@anton-seaice
Copy link
Contributor Author

Ill double check on Tuesday and then merge :-)

@anton-seaice anton-seaice merged commit a5ecf6b into main Jan 28, 2025
2 checks passed
@anton-seaice anton-seaice deleted the 209-new-build branch January 28, 2025 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants