Component updates to work with preindustrial+concentrations config

[dougiesquire]

It was brought up in our stand-up meeting today that the spack.yaml in the main branch isn't compatible with the current dev-preindustrial+concentrations configuration. This is because that configuration is currently using a prerelease deployment that uses a more recent version of WOMBATlite than is currently in the main branch.

The expectation was that the main branch spack.yaml should be compatible with the dev-preindustrial+concentrations configuration. This PR updates WOMBATlite and related components so that it is. Actually, it doesn't. It updates WOMBATlite and related components to the latest development versions. A small corresponding change will need to be made to the configuration for compatibility due to the addition of a couple more tracers.

I've also updated CICE to use the update_DaveBi branch. Are there any other updates we want to include, e.g. UM? @ccarouge, @blimlim

---

🚀 The latest prerelease access-esm1p6/pr54-1 at c665ee2 is here: #54 (comment) 🚀

---

🚀 The latest prerelease access-esm1p6/pr54-6 at 094d1cb is here: #54 (comment) 🚀

[github-actions]

🚀 Deploying access-esm1.6 dev_2025.03.0 as prerelease pr54-1 with commit c665ee2

Details and usage instructions

This access-esm1.6 model will be deployed as:

• dev_2025.03.0 as a Release (when merged).
• pr54-1 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr54-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-esm1p6-pr54-1 environment.

🛠️ Using: spack 0.22, spack-packages 2024.12.0, spack-config 2025.02.1

Details

It will be deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.12.0
• access-nri/spack-config version 2025.02.1

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

[dougiesquire]

Seems like a UM update might be needed too. If I try to run the dev-preindustrial+concentrations configuration with the pr54-1 prerelease built in this PR it crashes quickly.

However, the configuration runs successfully if I also use:

    um7: 
      require:
        - '@git.70b173e38c1c6f523e7cb7c61f3767f3c7d01671=access-esm1.6'

as in pr43-7.

[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/access-esm1-6-development/3114/129

[dougiesquire]

@MartinDix, do you have thoughts on this?

[manodeep]

@dougiesquire Based on the runs @blimlim did as part of this issue, we know that pr43-7 produces non-deterministic runs. Martin pointed out that there was a bug-fix in this comment - so at least the fix in this commit should be included.

You might be interested in what Jhan responds to this comment by Spencer. We can all use the same PR build :)

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr54-2 with commit 1069d86

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr54-2 with commit 299ae33

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-esm1.6 model will be deployed to Gadi as:

• dev_2025.03.0 as a Release (when merged).
• pr54-2 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr54-2

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-esm1p6-pr54-2 environment.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.12.0
• access-nri/spack-config version 2025.02.1

If the above was not what was expected, commit changes to config/versions.json in this PR.

[dougiesquire]

@dougiesquire Based on the runs @blimlim did as part of this issue, we know that pr43-7 produces non-deterministic runs. Martin pointed out that there was a bug-fix in this comment - so at least the fix in this commit should be included.

You might be interested in what Jhan responds to this comment by Spencer. We can all use the same PR build :)

Thanks @manodeep. I've just updated the UM to 86a4e1f which apparently should fix the non-determinism

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr54-3 with commit 7955e4d

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-esm1.6 model will be deployed to Gadi as:

• dev_2025.03.0 as a Release (when merged).
• pr54-3 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr54-3

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-esm1p6-pr54-3 environment.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.12.0
• access-nri/spack-config version 2025.02.1

If the above was not what was expected, commit changes to config/versions.json in this PR.

[dougiesquire]

@blimlim, would you be able to review? These are the corresponding configuration changes we'll need to make (obviously I'll change the module once this PR is merged).

[blimlim]

Thanks @dougiesquire! All looks good to me

[harshula]

Hi @chrisb13 , The cice4 update_DaveBi branch needs ACCESS-NRI/cice4@889aae8 from the access-esm1.5 branch to support being built by oneapi@2025.0.4. Do you want to cherry-pick the commit and push the update to the update_DaveBi branch or do you want me to do it?

[harshula]

Hi @dougiesquire , I'm maintaining a table of tags to use for oneapi@2025.0.4 support here: ACCESS-NRI/access-spack-packages#52 (comment)

For oasis3-mct, change access-esm1.5_2024.05.24 to access-esm1.5-2025.03.001

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr54-4 with commit a5f4f73

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-esm1.6 model will be deployed to Gadi as:

• dev_2025.03.0 as a Release (when merged).
• pr54-4 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr54-4

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-esm1p6-pr54-4 environment.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.12.0
• access-nri/spack-config version 2025.02.1

If the above was not what was expected, commit changes to config/versions.json in this PR.

[chrisb13]

Hi @chrisb13 , The cice4 update_DaveBi branch needs ACCESS-NRI/cice4@889aae8 from the access-esm1.5 branch to support being built by oneapi@2025.0.4. Do you want to cherry-pick the commit and push the update to the update_DaveBi branch or do you want me to do it?

From my perspective, happy for the cherry-pick to proceed.

@DaveBi, feel free to highlight any concerns.

[dougiesquire]

@harshula, should we also use a specific commit for CICE, given ongoing issues with Spack updating branches?

[harshula]

Hi @dougiesquire , Good idea! A commit hash or a git tag is a safer option.

[dougiesquire]

Hi @dougiesquire , Good idea! A commit hash or a git tag is a safer option.

Let me know when you've done the cherry-pick and I'll make the change

[harshula]

Hi @dougiesquire , Done: https://github.com/ACCESS-NRI/cice4/commits/update_DaveBi/

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr54-5 with commit 69497b1

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-esm1.6 model will be deployed to Gadi as:

• dev_2025.03.0 as a Release (when merged).
• pr54-5 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr54-5

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-esm1p6-pr54-5 environment.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2024.12.0
• access-nri/spack-config version 2025.02.2

If the above was not what was expected, commit changes to config/versions.json in this PR.

[harshula]

Hi @dougiesquire , Please use spack-packages tag: https://github.com/ACCESS-NRI/spack-packages/releases/tag/2025.03.002 in config/versions.json.

This will also include @manodeep 's fixes for gcom4 and ACCESS-NRI/access-spack-packages#210

[github-actions]

🚀 Attempted to deploy access-esm1p6 Prerelease pr54-6 with commit 094d1cb

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-esm1.6 model will be deployed to Gadi as:

• dev_2025.03.0 as a Release (when merged).
• pr54-6 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-esm1p6/pr54-6

When using the above modules, the binaries shall be on your $PATH.

For advanced users, this Prerelease is also accessible on Gadi via /g/data/vk83/prerelease/apps/spack/0.22/spack in the access-esm1p6-pr54-6 environment.

Configuration Information

This Prerelease is deployed using:

• access-nri/spack on branch 0.22
• access-nri/spack-packages version 2025.03.002
• access-nri/spack-config version 2025.02.2

If the above was not what was expected, commit changes to config/versions.json in this PR.

[blimlim]

Thanks @dougiesquire. Changes look good to me!

Following the stand up discussion on which versions we want to go in to this – I think it makes sense these versions to go in as is so that there's a test version that's easy to access, and then updates following further discussion/decisions could be made separately. Let me know what you prefer!

[dougiesquire]

Thanks @harshula and @blimlim

I think it makes sense these versions to go in as is so that there's a test version that's easy to access, and then updates following further discussion/decisions could be made separately.

Yup, I agree. I've tested this PR with these corresponding configuration changes and it runs successfully for a year so I think this should be a suitable base for testing. I'll merge this and ping you for a review of for config changes.