Modules

Main page: Software

Over the next few months ACEnet will be gradually transitioning to using Modules to manage user environment. During this period we will also be updating documentation on the website. It's highly recommend that users start adopting new instructions on how to get access to different software packages. If you prefer using the old method of explicitly changing environment variables then you can keep using it. December 16, 2011 (AST)

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 modified TCL 1.144 version.

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 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 modules

At each level of the hierarchy, there is either a default modulefile or a 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.).

In addition to that, only one environment variable is set: its name is the same as the name of the software package, 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.

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.
• 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 for the modulefiles 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 module load commands into your dot shell profiles to get often used modules loaded at the login time.
• Alternatively, you can load necessary modules right in your submission script before calling the main application binary.

Default environment

Currently the following modulefiles are loaded by default in every user's account: pgi, sunstudio, openmpi/pgi, totalview. Please check User Guide to verify that your dot shell profiles are configured correctly.