Environment modules

The use of a module system means most software is not accessible by default but has to be loaded using the module command. The reasons for this are that it allows RC to provide multiple versions of the software concurrently and allows users to easily switch between versions.

"Loading a module" sets or modifies a user's environment variables to enable access to the software package provided by that module. For instance, the $PATH variable might be updated so that appropriate executables for that package can be used.

Research Computing's current Lua based Lmod environment module system is hierarchical, with five layers to support programs built with compiler and library consistency requirements. Modules are only available to be loaded once their dependencies have been satisfied. This prevents accidental loading of modules that are inconsistent with each other. The layers include

  • Independent programs
  • Compilers
  • Compiler dependent programs
  • MPI implementations
  • MPI dependent programs

Thus, in order to load an MPI-dependent program, it's first necessary to load a compiler (eg, Intel), and then an MPI implementation (eg, IMPI). See examples below.

Enabling the current module system

User accounts created prior to Summer 2016 may be using an older modules system that only has access to earlier versions of software packages. RC highly recommends that all users switch to the Lmod modules system. Old modules will not work on Summit!

Switch to the new modules collection
/curc/tools/utils/switch_lmod.sh -r
Revert to the legacy modules collection

Common commands

The typical usage of the module command is outlined in the following table.

The module command may be shortened to the ml alias, with slightly different semantics.

module avail (ml av)
List available software. If a module is not listed here, it might have an unmet dependency and thus be unavailable for loading until a package higher in the module hierarchy is loaded.
Search for not-listed software using the module spider command.
module spider openmpi (ml spider openmpi)
Search for particular software. In this example we are searching for the OpenMPI library.
module load gcc (ml gcc)
Load a module to use the software. In this example we are loading the GNU Compiler Collection. We have not specified a version, so the default version will be loaded.
module load gcc/6.1.0
Load gcc version 6.1.0
module unload gcc (ml -gcc)
Remove/unload a module.
module swap gcc intel (ml -gcc intel)
Swap a module. In this example we are swapping gcc for intel. This will unload gcc and load intel, if there are any gcc dependent modules they will also be unloaded and the intel dependent versions (if available) will be loaded in their place.
module purge (ml purge)
Remove all modules. Note, that the slurm module will not be unloaded with this purge as it is sticky. If a user wants to unload a sticky module, they must specify the --force option.
module save foo (ml save foo)
Save the state of all loaded modules. In this example we are saving all loaded modules as a collection called foo.
module restore foo (ml restore foo)
Restore a state of saved modules. In this example we are restoring all modules that were saved as the collection called foo.

Additional module sub-commands are documented in the module help command.

Loading modules in Slurm jobs

In order for an application running in a Slurm job to have access to any necessary module-provided software packages, those modules need to be loaded in the job script. Module load commands should be placed after any #SBATCH directives and before the actual executable is called.