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).
Alternatively, you may load modulefiles on the login node and let the job inherit these settings (which it will do by default). See below for more information about these two methods.
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.
| Command | Description |
|---|---|
module avail pattern |
Lists all modules that have pattern in their name. For example: module avail para |
module avail |
Lists all available modules for use on the CSF (this shows what software has been installed). |
module list |
Lists all of the modules that you have currently loaded in your environment, if any. |
module list pattern |
Lists modules that you have currently loaded in your environment that have pattern in their name. For example module avail slu |
module load modulename |
Loads module modulename |
ml |
Lists all of the modules that you have currently loaded in your environment. |
ml modulename |
Loads module modulename |
module unload modulename |
Unloads module modulename and clears any settings made by the module from your environment |
module switch oldmodulename newmodulename |
Switches between two modules, unloading one and loading the other |
module purge |
Unload all modules from your environment. Very useful for starting with a clean environment (alternatively just log out and back in again). Note the the slurm modulefile (needed to submit batch jobs) will NOT be purged. |
module help modulename |
May show longer description of the module if present in the modulefile |
module helpmodule -H |
Show help about the module command |
module show modulename |
Shows all of the settings that would be made by the module if you were to load it. Very useful to see what the module does. |
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: