-
Notifications
You must be signed in to change notification settings - Fork 0
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
spack.yaml: depend on generic tracers Spack components #82
base: main
Are you sure you want to change the base?
Conversation
* "spack": "0.22", * "spack-packages": "development", * "spack-config": "2024.10.03"
33ff4bd
to
7e7a627
Compare
The model version in the
|
!bump major |
❌ Failed to bump version or commit changes, see https://github.com/ACCESS-NRI/ACCESS-OM2/actions/runs/11212418716 ❌ |
Token has expired. Will regenerate one tomorrow...considering making it have a longer lifespan 😅 |
Would be good to have a mechanism to remind us when things like this are expiring. Can we generate tokens through an API and set through an API? |
🚀 Deploying access-om2 Details and usage instructionsThis
This Prerelease is accessible on Gadi using: module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-4 where the binaries shall be on your 🛠️ Using: spack DetailsIt will be deployed using:
If this is not what was expected, commit changes to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question at this point.
This is fine for testing, but just flagging we have some fork management discussions/decisons to make for those new components before merging.
spack.yaml
Outdated
cice5: '{name}/2023.10.19' | ||
mom5: '{name}/2023.11.09' | ||
mom5: '{name}/development' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This made me wonder, would we have namespace clash issues with modules in prerelease
if two PRs tried to create modules using the same tag or name?
ping @CodeGat for visibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect so, now that you mention it...!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we do development_2024.10.08
or dev_2024.10.08
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dev_2024.10.08
is sufficiently descriptive and a little less clunky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the future: could we isolate modules into separate namespaces, use the PR name as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we do that? Just change the name of the module, or something fancy with modules that I don't know?
🚀 Deploying access-om2 Details and usage instructionsThis
This Prerelease is accessible on Gadi using: module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-5 where the binaries shall be on your 🛠️ Using: spack DetailsIt will be deployed using:
If this is not what was expected, commit changes to |
🚀 Deploying access-om2 Details and usage instructionsThis
This Prerelease is accessible on Gadi using: module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-6 where the binaries shall be on your 🛠️ Using: spack DetailsIt will be deployed using:
If this is not what was expected, commit changes to |
Note: the Prerelease succeeded (and is usable), the workflow failed to collect some metadata as the updates to |
fb44950
to
799674f
Compare
🚀 Deploying access-om2 Details and usage instructionsThis
This Prerelease is accessible on Gadi using: module use /g/data/vk83/prerelease/modules
module load access-om2/pr82-7 where the binaries shall be on your 🛠️ Using: spack DetailsIt will be deployed using:
If this is not what was expected, commit changes to |
Hi @chrisb13 , @anton-seaice , @dougiesquire , This is ready for testing. |
I probably won't do any testing while on leave, but if anyone wants to try run this they can use this config. You'll obviously need to modify the |
Following @dougiesquire suggestion, we've ran a test using this branch (commit The test ran successfully for five years and produced output from ACCESS-OM2 with WOMBAT legacy in generic tracers. @pearseb also checked the output. NPP screenshot below. |
Can we get those modifications into this PR?
Nice. Was this up for debate? |
The modifications were small but also made to the config repo' (here) so not sure how they'd be incorporated into this PR..? |
Oh sorry, I misspoke. As you quite rightly point out the config repo isn't part of this PR, so ignore me. But you can push changes to that branch, or create a new branch with those changes, to make it easier to test. |
…55_ryf_wombatlite (12761ac) for this ACCESS-NRI/ACCESS-OM2#82.
Ok as discussed and above, now on a new branch on my own repo', here: |
@chrisb13 feel free to just push to the |
Opening this PR to create a pre-release build of ACCESS-OM2 with Spack-built generic tracers components for testing.