Lmod-style module file for gromacs on a cluster?

User discussions
1

GROMACS version: 2022.2
GROMACS modification: No

I’m installing Gromacs 2022.2 on an HPC cluster, where we use lmod-style modules for managing most software. Lmod is a scheme where, when you “load” a module, it changes the environment variables (PATH, LD_LIBRARY_PATH, etc.) so that the software you want to access is reachable, and it has a nice thing where when you “unload” a module, it reverts the paths back to their prior state.

Gromacs has the GMXRC scheme, which looks very cool – is it also reversible?

To use the lmod scheme, I could just call GMXRC from the module file at load-time, and then call its inverse (if it has one?) at unload-time.

Or maybe someone already has an lmod-style module file for gromacs?

Thanks in advance for any help you can offer!

2

GMXRC is not fully reversible. However, it correctly clears the old variables when a new GMXRC is loaded so that you can replace one version of GROMACS with the other. This is what makes up most of the code in GMXRC.bash 😁.

On our cluster, we extract (manually) the necessary variables from GMXRC and set them with prepend-path. The rest depends on how your module system is set up and how you want to manage different GROMACS versions (different modulefiles, symlinks, variants).

3

Actually I was wondering about the same, so it was good to know what is being done on the cluster used by the GROMACS core team. Manually replicating the GMXRC variables is tedious but helps also customizing the module beyond what GMXRC provides, e.g. to handle different builds, patched versions, etc.

A simpler alternative for a sysadmin (who needs to maintain modules for many packages these days!) could also be to define a “sticky” module like this:

add_property("lmod", "sticky")
execute { cmd=("source " .. GMX_PREFIX .. "bin/GMXRC"), modeA={"load"} }

This makes the module impossible to unload unless --force is used, which reflects the fact that GMXRC is not reversible.

However, with recent versions of Lmod it is still possible to switch between versions of the same “sticky” module:

$ module load sticky/1
$ module load sticky/2

The following have been reloaded with a version change:
  1) sticky/1 => sticky/2

and the switch is something that GMXRC is supposed to handle cleanly.

4

Thanks, this looks like a good option! I’ll also explore the variables “manually” – it’s easy enough to diff the environment before and after. Bash-completion is harder, but also less important in a batch/queuing context, and less important to reverse.