Modules

Overview

Modules is the system by which most software is made available. Modules allow, via a simple interface, the update of various paths (and other environment settings) that allow access to software.

The use of modules also provides a convenient way to switch between different versions of the same software (such as compilers or applications such as matlab which are updated frequently).

Module Commands

Your environment is controlled using the module command with various arguments. The most commonly used command is:

module load name/1.2.3

These commands can be used directly on the login node or in your jobscripts.

You may wish to search for modules on the login node while writing your jobscript AND do the actual loading of the modulefile inside the jobscript so that your jobs always use the same version of the application.

The full list of module commands is given below.

Module environment settings in batch

Modulefiles can be loaded:

• on the login node before you submit a batch job
• or from the jobscript when the job actually runs

There are pros and cons to each method but which method you choose is up to you – both are valid.

Loading a modulefile on the login node

The advantages of loading a modulefile on the login node before you submit the job are that you can check the name of the modulefile is correct (any spelling mistakes and the modulefile won’t be loaded). You could also check the settings the modulefile makes (e.g., an environment variable) and then use that in your jobscript. The disadvantage is that the particular modulefile name used is not recorded in your jobscript. If you wish to run the job again (perhaps in a few months time) you may have forgotten which version of a modulefile you used.

Loading a modulefile in the jobscript

The key advantage of loading a modulefile in the jobscript is that the names of any modulefiles used by your job are recorded – this helps with reproducibility (you might want to run the job again in 6 months time so having the modulefiles written in the jobscript shows exactly which apps were used by the job.) However, if you spell a modulefile name incorrectly the mistake will only be detected when the job runs. Your job will probably fail and you’ll have to resubmit the job, waiting in the queue again.

Example of each method

You should write your jobscripts for the modulefile method you prefer:

Using your own Modulefiles

You can write you own modulefiles, using either TCL or LUA scripting languages. These should be stored in a folder named ~/modulefiles (i.e. the folder is in you home dir.)

For example

mkdir -p ~/modulefiles/myapp
cd ~/modulefiles/myapp
gedit 1.2.3.lua
  #
  # Write the LUA script modulefile

# OR, write a TCL modulefile
gedit 1.2.3
  #
  # Ensure the first line of the file is:
#%Module#

# Now, when you wish to use this module file, do:
module load use.own
module laod myapp/1.2.3

Note that if you’ve previously written your own modulefiles on CSF3 then they are stored at:

~/privatemodules

So to make these available on CSF4, you should do:

#either
module load use.own.csf3
#or
module use ~/privatemodules

#and then
module load <your_privatemodule>

However, note that if your own CSF3 modulefiles try to load CSF3 system-wide modulefiles (e.g., a CSF3 compiler) then it will fail to load on CSF4.
Also, if the program/code compiled in CSF3 uses any specific version of library that is not available in CSF4, the module will load okay, but the program/code will crash when run.
It is better to re-compile your software/code in CSF4 and place their module files in ~/modulefiles instead.