Changing model versions is onerous and error prone

[aidanheerdegen]

In the process of changing model executables to spack deployed versions (or just changing between existing spack deployed versions) it has become clear that changing the full executable paths is onerous and somewhat error prone.

The paths are long and complicated. They need to be copied from the spack.location file of a deployment, and they are versioned for the model component code and so do not show the ACCESS-OM2 version from which they came. It is the access-om2 package that contains the overall model versioning. For example, when updating to the deployment which introduced restart reproducibility all the model component versions were unchanged, though the build hashes were different, because they used an updated version of spack-packages and spack-config.

I think we should move to using generic model names (without paths) in the exe fields and use the module system to inject the correct directories into the PATH environment variable, e.g.

model: ocean
   exe: fms_ACCESS-OM.x

...

modules:
  use:
      - /g/data/ik11/spack/0.20.1/modules/access-om3/linux-rocky8-cascadelake
  load:
      - access-om2/2023.03.0

This has a few benefits:

1. Ensures model components all come from the same deployment
2. Easier to switch between versions. Only the version in the loaded module is changed: this is good for users, but also for devs updating configs, and reviewers who can know the correct versions are being used
3. Makes configs more portable to other systems (future goal)

The rationale for using full paths was that it less error prone. I no longer think that is the case.

Note this would require this payu issue to be closed with an update

payu-org/payu#379

Note also the details of how to specify the binary paths might depend on the final design of the payu update.

[CodeGat]

So, this is a change to the metadata.yamls on the config branches, then?

[aidanheerdegen]

So, this is a change to the metadata.yamls on the config branches, then?

Yes it would be a change to config branches, but only config.yaml.

I'm not saying we should do this immediately, but before we need to change ACCESS-OM2 versions again.

[aidanheerdegen]

Would value your opinions @minghangli-uni and @dougiesquire as you've just gone through this update process.

[dougiesquire]

Relevant: COSIMA/access-om3#133

[micaeljtoliveira]

@aidanheerdegen In case the required changes to payu are too complex, I've recently realised there is another way of simplifying the exec path, which is to use the spack environment view. In the spack.yaml file one can specify a custom path for the view like this:

  view:
    default:
      root: $spack/../opt/views/access-om3-0.x.0
      projections:
        all: '{architecture}

Then the exec path in the payu config can be set to:

exec: /g/data/ik11/spack/0.21.2/opt/views/access-om3-0.x.0/linux-rocky8-cascadelake/bin/access-om3-MOM6-CICE6

This is not as neat as doing simply exec: access-om3-MOM6-CICE6, but it should be simpler and less error prone to update than the current path. In particular, this path can be determined programmatically, as it contains no hashes.

[aidanheerdegen]

I've recently realised there is another way of simplifying the exec path, which is to use the spack environment view

That is cool.

Is it necessary to spacktivate an environment to use this feature?

[micaeljtoliveira]

Is it necessary to spacktivate an environment to use this feature?

No. You don't even have to load any modules, because spack injects all the rpaths into the executable...

[aidanheerdegen]

If we did use module load access-om2/version to switch between versions it would be difficult to check that the executables in manifests/exe.yaml correspond to the correct paths.

If there was a machine readable version of the spack.location file in the associated model release this could be read and used to check the paths are correct.

[CodeGat]

What is the status of this issue, given the above linked payu issue is merged?

[dougiesquire]

It is now substantially less onerous and requires only changing the version of the loaded module in the config.yaml - e.g. see here

[aidanheerdegen]

I think we can call this solved.