Skip to content
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

Updates for BGC build #2

Merged
merged 10 commits into from
Mar 27, 2024
Merged

Updates for BGC build #2

merged 10 commits into from
Mar 27, 2024

Conversation

aidanheerdegen
Copy link
Member

@aidanheerdegen aidanheerdegen commented Mar 19, 2024

Add changes to convert from ACCESS-OM2 build type to ACCESS-OM2-BGC.

Requires changes to the README and the spack.yaml to use type=ACCESS-OM2-BGC which was added to the MOM5 spack package (see ACCESS-NRI/spack-packages#72).

@CodeGat
Copy link
Contributor

CodeGat commented Mar 19, 2024

Whoops, I'll need to update the CI in this repository since it was created before I got CI working.

@CodeGat
Copy link
Contributor

CodeGat commented Mar 19, 2024

Regarding https://github.com/ACCESS-NRI/ACCESS-OM2-BGC/pull/2/files#diff-e8582e74fa156f4e5729a850e52b24f2fde2d815c2c9c360f88c4cf90db851abL8 (spack.yaml Line 8 - [email protected]) - would we change the name of the package? I feel that it could clash with the environment names in prerelease/release if the versions are the same (for example, access-om2-2024_02_1).

@CodeGat
Copy link
Contributor

CodeGat commented Mar 19, 2024

So regarding the spack package for access-om2-bgc:

  • don't change the spack package name, but hardcode the name of the spack environment to include a -bgc (access-om2-bgc_2024_03_0). This would mean the environments wouldn't clash, but the packages outside the environment might, if the versions are the same. Needs more testing.
  • add an entry in spack-packages for BGC. This wouldn't clash with an environment or package name, but might be nonstandard - do we really want to do a new spack-package for every variant?

@harshula how are variants handled in spack, regarding the package name? If you do a spack find would there be something like access-om2+bgc for a bgc variant?

@aidanheerdegen
Copy link
Member Author

  • don't change the spack package name, but hardcode the name of the spack environment to include a -bgc (access-om2-bgc_2024_03_0). This would mean the environments wouldn't clash, but the packages outside the environment might, if the versions are the same.

To be specific, this would require changes to the CD workflow to be able to pass in a spack environment name? As it currently defaults to the spack package in spack.yaml:

https://github.com/ACCESS-NRI/ACCESS-OM2/blob/main/.github/workflows/cd.yml#L28

  • add an entry in spack-packages for BGC. This wouldn't clash with an environment or package name, but might be nonstandard - do we really want to do a new spack-package for every variant?

No I don't think we do, but this doesn't have to be the last word. Unscrambling this egg wouldn't be too painful: leave deployed model versions as-is and new ones could follow a new approach.

This is part of why being able to rely on module load would be nice: it frees us a bit on the implementation detail as we wouldn't need to hard-code paths in model configs, which means we could update how we do it relatively simply and it could be backwards compatible.

@harshula how are variants handled in spack, regarding the package name? If you do a spack find would there be something like access-om2+bgc for a bgc variant?

I can answer: yes.

$ spack find -Lv mom5
-- linux-rocky8-x86_64 / [email protected] -----------------------
uznvr36p3km4qmjvdrxin7nhfyjubmd3 mom5@master~deterministic~optimisation_report build_system=makefile
oucqhr5r4yupkapwb6vsnqh2i6ow4vod mom5@master~deterministic~optimisation_report+repro build_system=makefile
4q2un3c6if5hynashormlklggv55bng5 mom5@master~deterministic~optimisation_report+restart_repro build_system=makefile type=ACCESS-OM
aollz5h3gjqjhb3pkgfkkqqifm75hals mom5@master~deterministic~optimisation_report build_system=makefile type=ACCESS-OM-BGC
4jfyunr427g3rk667hcyir7xrfytlqoo mom5@master~deterministic~optimisation_report build_system=makefile type=MOM_solo
==> 5 installed packages

The packages are handled fine, but as you point out environment names would clash. It is possible to store environments in non-default locations. Could we add a prefix (subdirectory) that is the repo name, then any environment created therein is guaranteed to be unique on a per-repository basis only.

@CodeGat
Copy link
Contributor

CodeGat commented Mar 20, 2024

This branch will need to be rebased onto main to get the CI updates

Copy link

The model version in the spack.yaml has not been updated.
Either update it manually, or comment the following to have it updated and committed automatically:

  • !bump major for feature releases
  • !bump minor for bugfixes

@aidanheerdegen
Copy link
Member Author

!bump major

This is a the first version of a new model so needs a new major (CalVer) version.

Copy link

❌ Failed to bump version or commit changes, see https://github.com/ACCESS-NRI/ACCESS-OM2-BGC/actions/runs/8366824447

@aidanheerdegen
Copy link
Member Author

!bump major

Copy link

❌ Failed to bump version or commit changes, see https://github.com/ACCESS-NRI/ACCESS-OM2-BGC/actions/runs/8366852547

Copy link

The model version in the spack.yaml has not been updated.
Either update it manually, or comment the following to have it updated and committed automatically:

  • !bump major for feature releases
  • !bump minor for bugfixes

spack.yaml Outdated Show resolved Hide resolved
spack.yaml Outdated Show resolved Hide resolved
@CodeGat
Copy link
Contributor

CodeGat commented Mar 22, 2024

So currently the CI is failing because it hasn't taken into account the possibility that the projections would be anything but {name}/{version}. For example, mom5 has the projection {name}-bgc/0000.00.00. This PR should fix that, and we can get a deployment on the way: #4

Copy link

This ACCESS-NRI/ACCESS-OM2-BGC model will be deployed with the following versions:

  • 2024.03.0 as a Release (when merged).
  • 2024.03.0-8 as a Prerelease (during this PR). This can be accessed on Gadi via spack at /g/data/vk83/prerelease/apps/spack/0.20/spack once deployed.

It will be deployed using:

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

Copy link

This ACCESS-NRI/ACCESS-OM2-BGC model will be deployed with the following versions:

  • 2024.03.0 as a Release (when merged).
  • 2024.03.0-9 as a Prerelease (during this PR). This can be accessed on Gadi via spack at /g/data/vk83/prerelease/apps/spack/0.20/spack once deployed.

It will be deployed using:

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

@aidanheerdegen
Copy link
Member Author

Deployment is failing because the environment still specifies nci-openmpi which we've removed from spack-config

https://github.com/ACCESS-NRI/ACCESS-OM2-BGC/pull/2/files#diff-e8582e74fa156f4e5729a850e52b24f2fde2d815c2c9c360f88c4cf90db851abL24-L25

Copy link

This ACCESS-NRI/ACCESS-OM2-BGC model will be deployed with the following versions:

  • 2024.03.0 as a Release (when merged).
  • 2024.03.0-10 as a Prerelease (during this PR). This can be accessed on Gadi via spack at /g/data/vk83/prerelease/apps/spack/0.20/spack once deployed.

It will be deployed using:

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

@aidanheerdegen aidanheerdegen merged commit bf2cd3e into main Mar 27, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants