Module system

Many software packages need a special setup to run well. Often, these software packages suggest sourcing initialization scripts, setting environment variables like LD_LIBRARY_PATH, or modifying your shell configuration (e.g. ~/.bash_profile or even ~/.bashrc). This is a common source of errors, as different software installed on the machine can have conflicting requirements, and old settings can be unsuitable for newer versions of the same software. At the NSC you should not do this. Instead, you should use the module system, which has been designed to solve this exact problem.

NSC has a long list of software installed, and often in multiple versions to suit the needs of various user communities. The module system enables users to see what versions of what software packages are available, choose the ones they need for their work and have them set up correctly for their session, and not be bothered by all the rest of the software. In some cases, NSC also uses the module system to indicate what software versions are recommended to use, and which versions are recommended not to use.

Please see software documentation for how to use the actual software made available through the module system.

Loading and unloading modules

To get access to a software packages provided by NSC you load the corresponding module with e.g. module add python/2.7.14. This command makes the software available for the remainder of your session, e.g. adding the binaries to your PATH, the manual pages to MANPATH, etc. When you unload a module with e.g., module rm python/2.7.14, the changes made to your environment by loading the module are all reverted, restoring the previous state of your environment. This is also done when you try to load conflicting modules; the previously loaded one is removed and the replacement is added.

Note that in some cases with complicated module dependencies it is not so trivial to revert the changes to the environment done by that one single module, leaving everything else intact. Hence, in many cases when you need to revert the environment it is better to just issue module purge, which removes all loaded modules, and then start from scratch.

Furthermore, every time you log out your list of loaded modules is flushed. This is to ensure that each new session is unaffected by decisions in old ones (after all, the previous session could be days or months ago).

Load modules inside batch job scripts

Modules can also be loaded inside batch job scripts using normal module add ... commands, which is highly encouraged as it makes very explicit what software versions are used in the job. Not only does this help in debugging failed jobs, but it also makes jobs more reliably repeatable, since they no longer depend on what modules happen to be loaded at submit time (recall that the entire shell environment including module affected environment variables is recorded and preserved at batch job submission).

Modules loaded at build time do not need to be loaded again at runtime

The module system is integrated with the NSC compiler wrappers so that binaries compiled against NSC provided libraries will use the exact same version of these libraries at runtime, and enables the NSC mpprun MPI launcher to launch it using the exact right version of the correct MPI launcher for the binary. This means that you should not need to remember what modules you had loaded at build time, and you do not need to load them again in later sessions when you to want to run the binaries you built in order for the binary to find the correct libraries.

This is contrary to how modules are set up to work at some other HPC facilities, where the loaded modules (or even the order of loaded modules) will affect the behavior of compiled binaries, as this can cause different dynamic libraries to be loaded at runtime. In such environments the user must keep close track of what modules to load and in what order, to ensure that jobs will run successfully, possibly even requiring modules to be loaded and unloaded between commands in the batch job script depending on the combination of software that the job uses. This is not the case at NSC, where that information is stored in the binary itself at compile time using RPATH and tags.

For more detail please see the section on compilers.

Recommendations rather than default modules

In many places where modules are used, certain versions of software packages are marked as ‘default’. In this case it would be sufficient to issue, e.g., module load python to load the default version of Python.

However, NSC has made the decision to not mark specific versions of software as ‘default’. This is to avoid unexpected behavior when our recommended version of a software changes. Instead we provide recommendations inside the module system. Simply issue, e.g., module load python/recommendation to print out a message that explains which version of a software is currently the recommended one.

Usage

module --help         General help with module commands

module avail          List the available modules and recommendations

module load ...        Load the selected modules into your session (can also write: module add)

module list           List your currently loaded modules (will be flushed at logout)

module rm ...         Remove selected modules from your session

module purge          Remove all loaded modules

Note:

• The module command supports bash tab completion. I.e., you can often use the tab key to reduce the amount of typing necessary.

• Some helpful messages from the module command may suggest looking for modules with module spider <search string>. However, the way we have organized the modules at NSC, this is not useful for looking for end-user software. Instead just use module avail <search string> to search for suitable modules.

  (The module spider command can, however, be useful when looking for dependencies for compiling your own programs. More information is available under NSC Build Environment.)

Example

Check which modules are available:

[joel@tetralith1 ~]$ module avail

----------------------- /software/sse/modules ------------------------
   ABINIT/recommendation                                      (D)
   ABINIT/8.8.2-nsc1-intel-2018a-eb
   Amber/recommendation                                       (D)
   Amber/16-AmberTools-17-patchlevel-8-12-nsc1-intel-2018a-eb
   CDO/recommendation                                         (D)
   CDO/1.9.2-nsc1-intel-2018a-eb
   CGAL/recommendation                                        (D)
   CGAL/4.11-Python-2.7.14-nsc1-intel-2018a-eb
   CP2K/recommendation                                        (D)
   CP2K/5.1-nsc1-gcc-2018a-eb
   CP2K/5.1-nsc1-intel-2018a-eb
   Elk/recommendation                                         (D)
   Elk/5.2.14-nsc1-intel-2018a-eb
   FoX/recommendation                                         (D)
   FoX/4.1.2-nsc1-intel-2018a-eb
   HDF5/recommendation                                        (D)
   HDF5/1.8.19-nsc1-intel-2018a-eb
   ...

  Where:
   D:  Default Module

Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".

Now load the recommended version of Python:

[joel@tetralith1 ~]$ module add Python/recommendation

*************** NO MODULE LOADED *****************
***** Please also specify desired version ********
*** i.e. use the full name with version number ***

The recommended version of Python is 2.7.14-anaconda-5.0.1-nsc1

Type 'module load Python/2.7.14-anaconda-5.0.1-nsc1' to use that version.

A helpful tip is that tab completion is available for the module command, so a fast way to type out module add Python/recommendation is to type: module add Pyt tab /r tab.

Now load the module:

[joel@triolith1 ~]$ module load Python/2.7.14-anaconda-5.0.1-nsc1

This above command is easy to obtain simply by copy+paste the command that was spelled out in the recommendation text.