Locating pre-release binaries is difficult

[aidanheerdegen]

We're putting a lot of useful information in comments on PRs, but not the paths to the actual executables, or how to access the installed model using spack or module load:

This access-om2 model will be deployed with the following versions:

• 2024.04.0 as a Release (when merged).
• pr60-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:

• access-nri/spack-packages version 2024.04.20
• access-nri/spack-config version 2024.04.23

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

One use case of the pre-release functionality is to trial updates to a model, which requires utilising the pre-release builds in configurations.

There is work being done to make it easier to switch between model versions using module load, but it is still worthwhile providing information on the different ways the pre-release install can be accessed. e.g.

To access this pre-release:

1. With spack:

$ cd /g/data/vk83/prerelease/apps/spack/0.21
$ . spack-config/spack-enable.bash 
$ spack env activate access-om2-pr60-8
$ spack cd -e access-om2-pr60-8
$ ls
spack.location  spack.location.json  spack.lock  spack.yaml

The spack.location file shows all the paths where packages are installed, e.g.

$ grep mom5 spack.location
[email protected]=2023.11.09          /g/data/vk83/prerelease/apps/spack/0.21/release/linux-rocky8-x86_64/intel-2021.10.0/mom5-git.2023.11.09_2023.11.09-4o2xhb4kheyraqm6wwqxhvjqjgef3n4x

The mom5 binaries are in the bin sub-directory

$ ls /g/data/vk83/prerelease/apps/spack/0.21/release/linux-rocky8-x86_64/intel-2021.10.0/mom5-git.2023.11.09_2023.11.09-4o2xhb4kheyraqm6wwqxhvjqjgef3n4x/bin/
fms_ACCESS-OM.x  mppnccombine.spack

spack also adds this directory to the PATHwhen an environment is activated, so using which also works:

$ which fms_ACCESS-OM.x
/g/data/vk83/prerelease/apps/spack/0.21/spack/var/spack/environments/access-om2-pr60-8/.spack-env/view/bin/fms_ACCESS-OM.x

2. With environment modules:

$ module use /g/data/vk83/prerelease/modules/access-models/
$ module avail access
------------------- /g/data/vk83/prerelease/modules/access-models ---------------------
access-om2/pr60-8  access-om3/pr5-19
$ module load access-om2/pr60-8
Loading access-om2/pr60-8
  Loading requirement: oasis3-mct/2023.11.09-2mmvfad libaccessom2/2023.10.26-hz2oecd cice5/2023.10.19-ta4krzg mom5/2023.11.09-4o2xhb4

Once the the prerelease module is loaded the binaries should be in $PATH:

$ which fms_ACCESS-OM.x
/g/data/vk83/prerelease/apps/spack/0.21/release/linux-rocky8-x86_64/intel-2021.10.0/mom5-git.2023.11.09_2023.11.09-4o2xhb4kheyraqm6wwqxhvjqjgef3n4x/bin/fms_ACCESS-OM.x
$ which yatm.exe
/g/data/vk83/prerelease/apps/spack/0.21/release/linux-rocky8-x86_64/intel-2021.10.0/libaccessom2-git.2023.10.26_2023.10.26-hz2oecd5k7eezvt75tp5a536hpof5zqp/bin/yatm.exe
$ which cice_auscom_1440x1080_48x40_480p.exe
/g/data/vk83/prerelease/apps/spack/0.21/release/linux-rocky8-x86_64/intel-2021.10.0/cice5-git.2023.10.19_2023.10.19-ta4krzgyv5p4anup6ppsoksct4q5qyz2/bin/cice_auscom_1440x1080_48x40_480p.exe

Or they can be accessed directly (soon) with payu by having this in config.yaml

modules:
   use: /g/data/vk83/prerelease/modules/access-models/
   load: access-om2/pr60-8

So the question is, what additional information should we provide in the PR comments? Arguably the last module example is the most concise, straightforward to explain and easiest to implement.

[aidanheerdegen]

Comments welcome @CodeGat @dougiesquire

[CodeGat]

Linking #66

[dougiesquire]

Por qué no los dos?

[CodeGat]

I think the environment modules would be the best way to go for most people? I'm also considering the fact that the "This module will be deployed with the following versions..." comment is quite large already.
As for the spack-related stuff, I think it should be short and sweet, if we were going to add that in as well.

[CodeGat]

The spack way seems to be good for people who will be tinkering with the installation itself - in prerelease, we don't really mind what people do with the environments when they are deployed, although obviously we would prefer people make changes through the spack.yaml in the PR. So maybe it would be enough to say:

This prerelease is accessible using module use /g/data/vk83/prerelease/modules/access-models/ && module load access-om2/pr60-8, where the binaries shall be on your $PATH.
It is also accessible via spack in the access-om2-pr60-8 environment.

Or does it require a little more stuff?

[dougiesquire]

I'm happy with only providing info on the modules. Once Payu can find the executable from the environment module, that will definitely be the preferred option.

[dougiesquire]

It is also accessible via spack in the access-om2-pr60-8 environment.

Is the only/correct way to find where everything was installed to look in the spack.location file? Are there some docs you could point to at the end of this sentence?

[CodeGat]

You can also do spack find --paths inside the environment to get the equivalent spack.location :D

[dougiesquire]

This prerelease is accessible using module use /g/data/vk83/prerelease/modules/access-models/ && module load access-om2/pr60-8, where the binaries shall be on your $PATH.
It is also accessible via spack in the access-om2-pr60-8 environment.

I like this

[CodeGat]

Does "where the binaries shall be on your $PATH" make enough sense?

[dougiesquire]

Does "where the binaries shall be on your $PATH" make enough sense?

I think so, yes

[CodeGat]

Dunno what the priority would be, though

[aidanheerdegen]

You can also do spack find --paths inside the environment

But can you? Isn't this the weird error I encountered with spack trying to git fetch --tags?

I also like this

It is a nice distillation of the massive tsunami of information I put at the top.

[aidanheerdegen]

Por qué no los dos?

Because conciseness. I thought it would be too wordy to include both but Tommy has managed that nicely.

[CodeGat]

Alright PR enjoyers, I have a linked PR that will do just that :) Let me know if you want me to go through it

[CodeGat]

But can you? Isn't this the weird error I encountered with spack trying to git fetch --tags?

@aidanheerdegen I'd just tested it on access-om2-pr60-8 and access-om3-pr5-19 and both seemed to do spack find fine - this was in the 0.21 prerelease spack.