ACCESS-OM2 module files missing

[aidanheerdegen]

The ACCESS-OM2 releases are not available as modules (and they should be)

$ module avail access-om2
------ /g/data/vk83/apps/spack/0.20/release/modules/linux-rocky8-x86_64 --------
access-om2-bgc/2024.03.0  

But they are visible in the spack release environment:

$ spack env list
==> 4 environments
    access-om2  access-om2-2023_11_23  access-om2-2024_03_0  access-om2-bgc-2024_03_0

[CodeGat]

This PR (https://github.com/ACCESS-NRI/build-cd/pull/29) introduced this line: https://github.com/ACCESS-NRI/build-cd/blob/main/.github/workflows/deploy-2-start.yml#L94

@harshula would you remember what it was for? I remember you trialing this command as the modulefiles were not being added correctly before.

[CodeGat]

Looking at the spack documentation:

[root@e0d239fa9b8c spack]# spack module tcl refresh --help
usage: spack module tcl refresh [-hy] [--delete-tree] [--upstream-modules] ...

positional arguments:
  installed_specs     constraint to select a subset of installed packages

optional arguments:
  --delete-tree       delete the module file tree before refresh
  --upstream-modules  generate modules for packages installed upstream
  -h, --help          show this help message and exit
  -y, --yes-to-all    assume "yes" is the answer to every confirmation request

the --delete-tree -y seems quite destructive. However, we can add installed_specs as positional args - maybe we just need to be more constrained? Not sure.

Something to be mindful of is that it worked with multiple access-om2/* modules before - I feel like it remember seeing multiple of the access-om2/* modules. Maybe it was because of the access-om2-bgc/* modules being regenerated, it deleted the access-om2 ones.

[aidanheerdegen]

It is the case that the top level version is unique between installations, but it is not guaranteed that the component model versions are unique: the component model version, which reflects the source code version, can remain the same but the spack build hash can change. An example was changing to restart reproducibility: the model version didn't change, but the default variants were changed in the spack-package, and so the build hash changed, as did the executable that was built.

We need to add spack build hash information to the model component modules, e.g. cice5 and mom5, but not to the top level model module, in this case access-om2.

It is desirable to not have a the spack build information in the top level because it makes it more difficult to programmatically change the model version, which we want to do to make it easier to update configurations.

It is not possible to add {hash} to the module projections in the environment. The spack build hash is added by default and the length of the hash is configurable for all visible modules with the hash_length setting. The only way to remove the hash from the top level model module is to set hash_length: 0, which is the current setting.

The only way to have no hash information in the top level model module but include it in the component modules is by making all the model components implicit and setting hide_implicits: true in the environment, and remove exclude_implicits.

Hidden implicit modules have the default hash length (7) added to the module versions, and those modules are hidden from the module system by adding them to a .modulerc file:

$ cat cice5/.modulerc 
#%Module4.7
module-hide --soft --hidden-loaded cice5/2023.10.19-p3rnzdf

See https://spack.readthedocs.io/en/latest/module_file_support.html#customize-the-naming-of-modules

The component models can also be removed from the include list. It's not clear if this was a necessary precondition to make those component model packages "implicit". Regardless they were not required, and so should be removed to further simplify the spack.yaml.

[aidanheerdegen]

We might also need to remove the --delete-tree y option, which should no longer be required.

[CodeGat]

Agree on all points, except for the removal of the -y - we need the module refresh to be noninteractive

[CodeGat]

Note: the Release 0.20 doesn't have the [hide|exclude]_implicits in the same way as 0.21. So, we needed to disambiguate the components with component/<version>_[bgc_]<model version>. For example, for access-om2 2023.04.0, mom5 will be mom5/2024.01.11_2023.04.0 or mom5/2024.01.11_bgc_2023.04.0.

[CodeGat]

Release now has the modulefiles for access-om2, access-om2-bgc.