Payu's check for module uniqueness fails incorrectly

[anton-seaice]

If in config.yaml, I specify:

modules:
        - openmpi/4.1.5

and then do a payu run, using payu 1.1.4, the following error is generated:

Traceback (most recent call last):
  File "/g/data/vk83/apps/payu/1.1.4/bin/payu-run", line 10, in <module>
    sys.exit(runscript())
  File "/g/data/vk83/apps/payu/1.1.4/lib/python3.10/site-packages/payu/subcommands/run_cmd.py", line 133, in runscript
    expt.setup()
  File "/g/data/vk83/apps/payu/1.1.4/lib/python3.10/site-packages/payu/experiment.py", line 431, in setup
    self.setup_modules()
  File "/g/data/vk83/apps/payu/1.1.4/lib/python3.10/site-packages/payu/experiment.py", line 237, in setup_modules
    loaded_mods, paths = envmod.setup_user_modules(user_modules,
  File "/g/data/vk83/apps/payu/1.1.4/lib/python3.10/site-packages/payu/envmod.py", line 173, in setup_user_modules
    raise ValueError(
ValueError: There are multiple modules available for openmpi/4.1.5:
/apps/Modules/modulefiles:
openmpi/4.1.5
openmpi/4.1.5-debug

This behavior is incorrect, as openmpi/4.1.5 is the whole name of the module and prevents the user specifying the openmpi version.

The check at line 163 in envmod might need modifying with an additional check if the module name specified is an exact match to the available module, or converting to a warning.

[aidanheerdegen]

How big a blocker is this? Just thinking about prioritisation.

I'm guessing there is no work-around available?

[anton-seaice]

I didn't find this in any managed configuration. It might be minor, because the typical usecase is to specify a module load which is unique (e.g.
access-om3/63ed4a4777aeac0c62720ddbe7f85e4ed16f82eb_main ) and loads all the other modules as dependencies (including openmpi). For the specific case of module loading openmpi, if you don't include a module use for openmpi, payu will use the default which is not drastically different (openmpi 4.1.4).