mom5: remove access-gtracers and type variants

[harshula]

Closes #183

[aidanheerdegen]

If you don't mind I'd prefer @dougiesquire and @penguian to review as they're more familiar with the requirements so I think would be better placed to do this.

[dougiesquire]

Thanks @harshula. Looks good, but I'll do some testing now.

In the meantime, I think we decided to support building with legacy WOMBAT, which I think requires adding another version:

version	branch	type	access-gtracers
access-om2-bgc-legacy	master	ACCESS-OM-BGC	F

Looking at the MOM5 code, I think supporting this might require code changes since we've moved to spackified gtracers.

ADDED: I think we'll also need to talk about what to do with FMS for this version

[dougiesquire]

support building with legacy WOMBAT, which I think requires adding another version

Thinking about this more, I think perhaps a legacy_BGC variant might be better. I'll play around with this

[harshula]

Hi @aidanheerdegen , Do you still want #183 (comment) ?

[aidanheerdegen]

Hi @aidanheerdegen , Do you still want #183 (comment) ?

I think what I said still applies, unless there is some new information?

[dougiesquire]

Hi @aidanheerdegen , Do you still want #183 (comment) ?

I think what I said still applies, unless there is some new information?

Oh, I actually misread your original comment @aidanheerdegen. I thought you were saying we should support building with legacy BGC, but now I see you're saying we should only add that if/when someone needs it...

[aidanheerdegen]

Oh, I actually misread your original comment @aidanheerdegen. I thought you were saying we should support building with legacy BGC, but now I see you're saying we should only add that if/when someone needs it...

Yeah. Now I'm concerned this has created a whole bunch of work ...

[dougiesquire]

Yeah. Now I'm concerned this has created a whole bunch of work ...

In my opinion, I think we're pretty much there. I think I have everything working (currently testing with prereleases and will report back), but @harshula is just working on making the SPR implementation a little better.

@harshula may disagree about how close we are though...

[dougiesquire]

Hi @dougiesquire , You can use spack-packages tag dev-2025.04.002. It only contains changes to the MOM5 SPR.

@harshula, without corresponding changes to the access-esm1p5, access-esm1p6 and access-om2-bgc SPRs, I can only test ACCESS-OM2.

But for ACCESS-OM2, spack-packages dev-2025.04.002 gives the same answers as my test branch as expected:

Model	Prerelease PR	Configuration test PR	Historical reproducibility
ACCESS-OM2	ACCESS-NRI/ACCESS-OM2#102	dev-1deg_jra55_ryf dougiesquire/1deg_jra55_ryf_wombatlite	❌ see here ❌ see here

Regarding my question from yesterday, are you happy with the string legacy-access-om2-bgc?

It's not ideal, but I guess so... To me, a legacy_bgc variant for the access-om2 version is clearer, but I think you don't like that option? Also, you told me on Zulip that we couldn't assume there is a Spack version specified in the spec. Is that not what you're now doing or am I misunderstanding?

[harshula]

Hi @dougiesquire , There isn't a documented way to extract the version in a consistent way. I had to do a lot of debugging last week and reading source code to discover that the GitVersion class contained a member variable containing the non-git component version string.

[harshula]

Hi @dougiesquire & @penguian , I've marked this PR Ready for Review. I'm just running build tests of access-om2 at the moment.

[harshula]

Hi @dougiesquire , Completed successful builds of ACCESS-OM2 ([email protected]_2024.08.14=access-om2) and ACCESS-OM-BGC ([email protected]=legacy-access-om2-bgc) in a Docker container.

Can you please do your test runs on spack-packages tag dev-2025.04.004? Thanks!

[dougiesquire]

Testing with:

• spack-packages tag dev-2025.04.004
• MOM5 tag dev-2025.04.001

Model	Prerelease PR	Configuration test PR	Historical reproducibility
ACCESS-OM2	ACCESS-NRI/ACCESS-OM2#102	dev-1deg_jra55_ryf dougiesquire/1deg_jra55_ryf_wombatlite	❌ see here ❌ see here
ACCESS-OM2-BGC (legacy)	ACCESS-NRI/ACCESS-OM2-BGC#22	dev-1deg_jra55_ryf_bgc	✅ see here
ACCESS-ESM1.5	ACCESS-NRI/ACCESS-ESM1.5#35	dev-preindustrial+concentrations	✅ see here
ACCESS-ESM1.6	ACCESS-NRI/ACCESS-ESM1.6#79	dev-preindustrial+concentrations	✅ see here

As above, I think the answer changes to the ACCESS-OM2 configurations are expected.

[dougiesquire]

Thanks @harshula, looking good to me. A couple of questions/comments below.

Also, I'm curious about the planned order for merging things. Would it be best to get the following merged before merging this PR:

• ACCESS-NRI/MOM5#29
• ACCESS-NRI/GFDL-generic-tracers#17

[harshula]

Also, I'm curious about the planned order for merging things.

This goes first. Then we update relevant MDRs (spack.yaml). Then remaining PRs.

[dougiesquire]

Also, I'm curious about the planned order for merging things.

This goes first. Then we update relevant MDRs (spack.yaml). Then remaining PRs.

Okay, just noting that the changes in this PR won't work by default since they require the changes in the MOM5 development branch. E.g. spack install access-om2 fails.

Is there a reason why we can't merge the MOM5 PR first? Are those changes incompatible with the current MOM5 SPR on main?

[harshula]

Okay, just noting that the changes in this PR won't work by default

Hi @dougiesquire , Which changes in this PR are you referring to?

[dougiesquire]

Okay, just noting that the changes in this PR won't work by default

Hi @dougiesquire , Which changes in this PR are you referring to?

Ah right yeah sorry - the MOM5 SPR already didn't work by default. I.e. even before this PR the MOM5 SPR relied on changes in the MOM5 development branch. Please just ignore me.

[penguian]

Looks OK to me.

[penguian]

Approved, as discussed previously.