Deploy new ACCESS-OM3 0.4.0 using COSIMA build system

[anton-seaice]

Deploy

https://github.com/COSIMA/access-om3/releases/tag/0.4.0

with new update components per COSIMA/access-om3#209

---

🚀 The latest prerelease access-om3/pr39-2 at 6ef4337 is here: #39 (comment) 🚀

[github-actions]

🚀 Deploying access-om3 2025.01.0 as prerelease pr39-1 with commit f5570b2

Details and usage instructions

This access-om3 model will be deployed as:

• 2025.01.0 as a Release (when merged).
• pr39-1 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-om3/pr39-1

where the binaries shall be on your $PATH.
This Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-om3-pr39-1 environment.

🛠️ Using: spack 0.22, spack-packages 2024.07.08, spack-config 2024.11.27

Details

It will be deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.07.08
• access-nri/spack-config version 2024.11.27

If this is not what was expected, commit changes to config/versions.json.

[github-actions]

🚀 Deploying access-om3 2025.01.0 as prerelease pr39-2 with commit 6ef4337

Details and usage instructions

This access-om3 model will be deployed as:

• 2025.01.0 as a Release (when merged).
• pr39-2 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-om3/pr39-2

where the binaries shall be on your $PATH.
This Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-om3-pr39-2 environment.

🛠️ Using: spack 0.22, spack-packages 2024.07.08, spack-config 2024.11.27

Details

It will be deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.07.08
• access-nri/spack-config version 2024.11.27

If this is not what was expected, commit changes to config/versions.json.

[anton-seaice]

This is ready for an alpha release :-)

[micaeljtoliveira]

@anton-seaice I've tested compiling OM3 with the Intel OneAPI compilers and, minus one small issue fixed in ACCESS-NRI/spack-config#52, the code and its dependencies compile correctly.

I had a quick chat with @chrisb13 and we thought we could try bundling the change of compiler used for deployment along with the update to the new version. That would just required changing:
- '%[email protected]'
to
- '%[email protected]'
once ACCESS-NRI/spack-config#52 is merged. However, one should probably test this a bit more by actually trying to run some of the configurations with the resulting executable and see if there are no issues.

[anton-seaice]

Why not just do it in another release? Releases are free and this one at this point is not answer changing.

I tried `%[email protected]' previously and it seemed like it wasn't found ? I didn't investigate but I guess if '%[email protected]' works on your local instance it probably doesn't matter !

[micaeljtoliveira]

Why not just do it in another release? Releases are free and this one at this point is not answer changing.

Doing it here was @chrisb13 suggestion, so I'll let him answer that ;)

I tried `%[email protected]' previously and it seemed like it wasn't found ? I didn't investigate but I guess if '%[email protected]' works on your local instance it probably doesn't matter !

%[email protected] should become available when the PR I mentioned above is merged.

[anton-seaice]

It looks like there are a few when=%intel lines around the place that would need confirming too ..

e.g.

https://github.com/ACCESS-NRI/spack-packages/blob/288ef380159af4536137b40360b2a87c043b7ce1/packages/access-om3-nuopc/package.py#L58
https://github.com/ACCESS-NRI/spack-packages/blob/288ef380159af4536137b40360b2a87c043b7ce1/packages/access-om3-nuopc/package.py#L65

[anton-seaice]

I moved the oneapi discussion to #41

[chrisb13]

I've tested compiling OM3 with the Intel OneAPI compilers and, minus one small issue fixed in ACCESS-NRI/spack-config#52, the code and its dependencies compile correctly.

@micaeljtoliveira. Great to hear it's working! (Locally at least.)

Why not just do it in another release? Releases are free and this one at this point is not answer changing.

We had a chat about this on Friday. I'm told it's not currently working on the CI / current spack environments however and I've been convinced it's helpful to have a baseline with no answer changes to use as an answer-performance benchmark. There's also an issue of whether the OneAPI picks up current Cmake control statement (example) and this when=%intel. In short, we think it's helpful to release as is but quickly move to the new compiler once the above issues are ironed out.