Modules

Legacy documentation This page describes a service provided by a retired ACENET system. Most ACENET services are currently provided by national systems, for which please visit https://docs.computecanada.ca.

Main page: Software

The Environment Modules package, or Modules, is a convenient tool to modify a user's environment. Modules allow to set or change different shell environment variables, such as PATH and MANPATH, in a clean fashion. ACENET utilizes Modules to provide easy access to different pieces of software.

For every environment setting, there is a corresponding modulefile, which contains necessary instructions on how exactly a user's environment should be modified. The modulefiles can be loaded and unloaded dynamically and atomically, with the corresponding dependency and conflict resolution rules. This allows effective management of multiple versions of different applications and environments. Moreover, the Modules commands syntax is the same in every shell (whether it's bash or csh). You can find more information about Modules on the Modules website. The version of Modules installed at ACENET is a customized TCL v1.144.

See Usage tips below for important notes.

Examples

Here is an example to give you an idea how Modules work. Say, you want to get access to the Intel compilers, so you type

 $ module load intel

Once the modulefile is loaded, your environment is properly configured giving you access to the Intel compilers binaries and the compiler man pages:

 $ ifort
 $ icc
 $ man ifort

Naming convention

The modulefiles are organized in a hierarchy of files and directories. The top level directory corresponds to the name of a package, and everything below the top level corresponds to a version of that package like so:

 package-name/version
 package-name/version-major/version-minor

Here are some examples:

 intel/12.0.0.084, octave/3.2.4, openmpi/pgi/1.2.9

Note that all modulefile names at ACENET are specified in the lower case.

Default versions

At each level of the hierarchy, there is usually a default modulefile or a default subdirectory. Users have the choice of loading modulefiles by their full name (package-name/version), or by the name of a software package (package-name), i.e. short name. In the latter case, the default at each nested level will be selected to determine which modulefile to load.

Usually, the default is either the latest or the most stable version of the package, and it's set at ACENET's discretion in order to maintain a consistent environment. Users are free to load explicitly whichever version they prefer, taking care of loading other required modulefiles beforehand, or unloading conflicting ones.

What is configured

Every modulefile contains only those changes to the environment that would be made if one followed the instructions provided by the developers of a software package (e.g. user guide, readme file, setup script, etc.). Users can inspect every module file with the following command

$ module show modulefile-name

In addition to that, only one environment variable is set. Its name is the capitalized name of the modulefile (without spaces or hyphens), and it contains a path to where the software is installed. For example, the modulefile gromacs/4.5.5 sets the environment variable GROMACS that contains the following path /usr/local/gromacs-4.5.5. This environment variable can be used by users in different scripts or compilation options (see for example FFTW).

Basic commands

The general syntax to use Modules is as follows:

 $ module [ command ] [ -t | -l ] [ modulefile... ]

You can get the list of all available commands by calling module with no options. Here is a list of the most useful commands:

list

Show currently loaded modules

avail [ modulefile... ]

List all available modulefiles

load modulefile...

Load modulefile(s) into the shell environment

unload modulefile...

Remove modulefile(s) from the shell environment

switch modulefile1 modulefile2

Switch two modules, i.e. unload modulefile1 and load modulefile2. You can use either short of full names here.

purge

Unload all loaded modulefiles

show modulefile...

Display information about one or more modulefiles. The show command will list the full path of the modulefile(s) and all (or most) of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)

whatis [ modulefile... ]

Display the information set up by the module-whatis commands inside the specified modulefile(s). If no modulefile is specified, all ’whatis’ lines will be shown.

help [ modulefile ]

Print the usage of each command. If an argument is given, print the module-specific help information for the modulefile.

Usage tips

• Many software packages have several versions available. You can see all available modules with module avail package-name.
• Before loading a modulefile in your submission script, try to load it in your shell interactively in order to determine which other modules are required to be loaded or unloaded first. Or, alternatively, you can use module show to see conflicting and required modulefiles.
• If your login shell is bash then you can use the autocomplete feature on the command line for the modulefile names by pressing the Tab key. This will work for both loaded and unloaded modules.
• Please remember that if you are using csh inside your submission scripts, then your current login shell environment (i.e. loaded modules) will not be inherited by your job at the submission time. Consider the two options below.
• You can put any module commands into your dot shell profiles, for example, to get often used modules loaded automatically, or to unload certain modules.
• Alternatively, you can load necessary modules right in your submission script before calling the main application binary (this is the way ACENET recommends for the majority of packages installed ACENET-wide).
• Finally, if certain modules present complicated dependencies that conflict with your current environment, it may be easier to do module purge first in your submission script before loading required modulefiles (see for example VASP).
• Do not forget that with most applications, if you compile a program with certain modules loaded, you will need the same modules loaded to run it.

Default environment

Currently, the following modulefiles are loaded by default in every user's account:

pgi
openmpi/pgi

Please check the User Guide to verify that your dot shell profiles are configured correctly.