Modules

On the HPC sytem, most user-level applications are invoked by means of modules. This system allows different versions to coexist and automatically sets paths. On the HPC system it is not necessary to source any initialization scripts. Appropriate modules must be loaded in SLURM job scripts in order to set the environment for your application. Note that the 'default' version of a module may change, so if you are developing applications yourself we highly recommend that you load explicit versions of modules; that is, do not invoke the default X, but specify a version.

Basic Commands

List all available software:

module avail

Load the environment for a particular package:

module load thepackage

For example, to load the default version of Matlab, run

module load matlab

If you do not wish to use the default version chosen by the modules environment, you may specify a path to the module script. For example, to select the MVAPICH2 version of the LAMMPS software, run

module load lammps/mvapich2

To further specify a version number, run

module load lammps/mvapich2/2014

Delete a module:

module unload thepackage

List all modules you have loaded in the current shell:

module list

Clear all modules you have loaded and return to the default state:

module purge

More about these commands can be found in the documentation. Most users need only examine the sub-commands section. The FAQ may also be useful.

Modules in Job Scripts

After the definition of job variables, and before the command line to run the program, add module load X lines for every application that you want included in your run environment. For example, to run R version 3.1.1 your job script should resemble the following:

#!/bin/bash
#SBATCH -p serial
#SBATCH -A MyAcct
#SBATCH -n 1
#SBATCH --time=00:10:00
#SBATCH --mem-per-cpu=1000

module load R/3.1.1
echo "Running R on $(hostname)" 
Rscript myScript.R

Please contact us if you encounter any problems using these applications in your job scripts.

Creating Your Own Modules

If you frequently use a piece of software that you have installed locally, you can write your own module script to make it convenient to load your software.  Module scripts are written in the Tcl language with some specialty commands.  See the modulefile documentation for more details.

First create a new directory in your home or other accessible space. In our example we will call it my-modules. Now cd into that directory, then run:

% cp -rp /share/apps/modulefiles/tophat /*

Once the the files have been copied, run:

% export MODULEPATH=$MODULEPATH:~/my-modules
% module avail

You will see now that you have your own module. Now try to edit the file ~/my-modules/tophat/. It will look something like this:

#Module3.0#######################################################################
#Created on Thu Apr 17 12:14:49 EDT 2014.
#tophat - 2.0.11

proc ModulesHelp { } {
    puts stderr "\tThis module loads tophat version 2.0.11\n"
}
module whatis "loads tophat version 2.0.11."

if {{ [ module-info mode load ] } {
    if { ! [ is-loaded bowtie2/2.2.3 ] } {
         module load bowtie2/2.2.3
    }
}
set version  2.0.11
prepend-path /share/apps/tophat/2.0.11/bin

You can see that the purpose of the module scripts is to set the correct environmental variables (usually $PATH, and often other library path variables), and to ensure that the software dependencies are satisfied, e.g. tophat 2.0.11 needs to know where bowtie2/2.2.3's libraries, headers, and binaries are located. After you compile a new application, try renaming the module file and folder you copied to match the name and version of the software you just installed. Then update the contents of the module file with the correct environment variable values and (if applicable) software dependencies.