How To Use Module Command

HPC cluster systems typically have a large number of software packages installed. Often there will be several versions provided for a package where it will be necessary for a user to choose between them. Equally, two different packages may clash with each other: for example, the commands for Intel MPI and Open MPI would overlap if simultaneously installed.

Everyday use
Default versions
Dependencies

Everyday use

On turing node we use the modules package to manage the user environment for the installed packages. This makes it simple to use different packages or switch between versions of the same package without conflicts.

To get a list of available packages, use:

module avail

To load a module to set up your environment to use a package you type:

module load <package>

replacing with the relevant module name. For example to load Matlab use:

module load matlab

To get a list of currently loaded packages:

module list

To unload a specific module, use:

module unload <package>

replacing <package> with the relevant module name. For example to unload Matlab use:

module unload matlab

To unload all loaded modules, use:

module purge

Default versions

Environment modules also support the concept of default versions. The default version, where it exists, is shown in the output of module avail e.g. module load gcc will load here gcc8.3.0, since it is marked as default. If you wish to load the 7.4.0 version then you will need to specify module load gcc/7.4.0. For example:

$ module avail gcc
----------------------------- /usr/share/Modules/modulefiles/compilers 
gcc/4.9.3          gcc/5.4.0          gcc/6.3.0          gcc/7.4.0          gcc/8.3.0(default) gcc/9.2.0-c7

$ module load gcc
$ module list
Currently Loaded Modulefiles:
  1) gcc/8.3.0

$ module purge
$ module load gcc/7.4.0
$ module list
Currently Loaded Modulefiles:
  1) gcc/7.4.0

Sometimes we stick with an older version as the default, since a lot of people may still be using that version, and will require checking of scripts and communication to all users of the package. For popular packages, we rarely make the newest version the default one, due to the potential for introduction of incompatibilities or inconsistent results.

Dependencies

Some of the software provided by a module may in turn depend on software provided by another module. For example, a aster tool implementation will require a bundle of tools and libraries needed. These cases may be handled by module dependencies. On Liger, the module system is set up to load dependent modules automatically rather than requiring users to satisfy the dependencies first. We see that loading this ASTER module also loads python, lapack, intel, gcc

$ module load aster
$ module list
Currently Loaded Modulefiles:
  1) gcc/4.9.3   2) lapack/3.6.1/gcc/4.9.3   3) python/2.7.12/gcc/4.9.3   4) intel/2015.3.187          5) aster/11.0.10