Deploy FRE-NCtools prerelease

[dougiesquire]

DO NOT MERGE

This is a PR to create a prerelease of FRE-NCtools. This is very much a stop-gap to provide a deployment of FRE-NCtools while we work out the best way to release these sorts of tools.

To get around the CI checks, this PR replaces the access-om3 spec in the environment with fre-nctools.

See #44

---

🚀 The latest prerelease access-om3/pr45-3 at bad5555 is here: #45 (comment) 🚀

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-1 with commit ad4f27d

🖥️ Gadi Deployment ❌

[harshula]

Hi @dougiesquire , You'll have to update config/versions.json so that the latest tag, 2025.02.1 of spack-packages is used.

[dougiesquire]

Good point, thanks @harshula

I realise I'm also unclear on how to include fre-nctools in the environment? I can't add it to specs because the CI only allows one spec, and I don't think adding it to packages will do anything (currently testing now). @aidanheerdegen

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-1 with commit cced16c

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-om3 model will be deployed to Gadi as:

• 2025.01.0 as a Release (when merged).
• pr45-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/pr45-1

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-om3-pr45-1 environment.

Configuration Information

This Prerelease is deployed using:

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

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

[aidanheerdegen]

I realise I'm also unclear on how to include fre-nctools in the environment? I can't add it to specs because the CI only allows one spec, and I don't think adding it to packages will do anything (currently testing now)

Ugh. I thought we could add more in the spec, and only the first entry was special, but I may have been mistaken. I defer to @CodeGat for the definitive word.

You're right that it won't be installed if it's just a package and nothing depends on it. So if we can't include in the spec then you'll have to update the access-om3 package to depend on fre-nctools I suppose.

Sorry if this is a mite more complex than I might have made out ... ;) <airly waves hands>

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-3 with commit a6b2037

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-3 with commit 5f66fa5

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-3 with commit 284b661

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-3 with commit 3be3c0e

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-2 with commit 776e826

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-om3 model will be deployed to Gadi as:

• 2025.01.0 as a Release (when merged).
• pr45-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/pr45-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-om3-pr45-2 environment.

Configuration Information

This Prerelease is deployed using:

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

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

[CodeGat]

I can update the schema to allow more than one spec, pending a discussion with the team tomorrow. I understand that there is appetite for (for example) having multiple compilers being built at once, etc, which we should support I think - especially since the Build CI 2.0 will make heavy use of matrix builds etc.

The main reason for requiring a single spec is that a Release should be as simple as possible, containing a single model. Maybe Prereleases shouldn't have that restriction, but it will be difficult to enforce that kind of thing at merge-time. Maybe it can be another relaxing of the rules that is already in place with Draft PRs... 🤔 anyway, I'll update this tomorrow with more thoughts.

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-3 with commit 91c7c56

🖥️ Gadi Deployment ❌

[github-actions]

🚀 Attempted to deploy access-om3 Prerelease pr45-3 with commit bad5555

🖥️ Gadi Deployment ✔️

Usage Instructions

This access-om3 model will be deployed to Gadi as:

• 2024.05 as a Release (when merged).
• pr45-3 as a Prerelease (during this PR).

This Prerelease is accessible on Gadi using:

module use /g/data/vk83/prerelease/modules
module load access-om3/pr45-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-om3-pr45-3 environment.

Configuration Information

This Prerelease is deployed using:

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

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

[dougiesquire]

I'm a dimwit and I've made an absolute hash of this PR. But I think I have managed to inveigle the CI checks and get a working prerelease of FRE-NCtools:

$ module use /g/data/vk83/prerelease/modules
$ module load fre-nctools/2024.05
$ which make_hgrid
/g/data/vk83/prerelease/apps/spack/0.22/release/linux-rocky8-x86_64/intel-2021.10.0/fre-nctools-2024.05-sy7yj4ssg2jmojoz6j33assnpipdu46s/bin/make_hgrid
$ make_hgrid --help



                    Usage of make_hgrid

   make_hgrid --grid_type grid_type --my_grid_file my_grid_file
...

@aidanheerdegen, @CodeGat let me know if you're okay with what's done here. If so, I might close this and redo in a new PR to tidy things up a bit.

[CodeGat]

I don't know how you managed to ballerina tip toe around the restrictions so elegantly but I'm impressed, and a little scared. I'll chat with @aidanheerdegen today 😁

[aidanheerdegen]

I don't know how you managed to ballerina tip toe around the restrictions so elegantly but I'm impressed, and a little scared.

He's ditched ACCESS-OM3 completely, which ISTR I had mentioned as a possibility in another discussion, but had subsequently forgotten, so sorry if that took longer than it should have.

[CodeGat]

Don't merge this!