Modules#
Enviroment Modules are a tool to help users manage their linux enviroment.
On a HPC you may have many different conflicting pieces of software.
Modules allow you to pick and choose the software you want available to you.
https://modules.sourceforge.net/
https://en.wikipedia.org/wiki/Environment_Modules_(software)
How to use Modules#
The first thing to check is a list of the modules currently active for you:
module list
When you sign into the login node, a default set of modules will be loaded. You will see something like this:
Currently Loaded Modules:
1) autotools 2) prun/2.2 3) gnu9/9.4.0 4) hwloc/2.7.0 5) ucx/1.11.2 6) libfabric/1.13.0 7) openmpi4/4.1.1 8) ohpc
You may want to unload all the modules, so you can load a custom set:
module purge
Then if you run module list again, you should see none listed:
No modules loaded
Next let’s check which module are available for us to load:
module avail
----------------------------------------------------------------------------------------- /opt/ohpc/pub/modulefiles -----------------------------------------------------------------------------------------------------------------
EasyBuild/4.6.2 charliecloud/0.15 gnu12/12.2.0 golang/1.20.3 java/8.0_371 libfabric/1.13.0 ohpc papi/5.7.0 singularity/3.7.1 ucx/1.11.2
autotools cmake/3.24.2 gnu9/9.4.0 hwloc/2.7.0 java/20.0.1 (D) magpie/2.5 os prun/2.2 stata/17 valgrind/3.19.0
Where:
D: Default Module
We don’t see every module listed here, as some modules have dependencies. Most of which depend on the GNU compiler. Let’s load gnu9/9.4.0 and check what additional module appear. We use the module load command:
module load gnu9/9.4.0
module avail
--------------------------------------------------------------------------------------- /opt/ohpc/pub/moduledeps/gnu9 ---------------------------------------------------------------------------------------------------------------
R/4.1.2 gsl/2.7 hdf5/1.10.8 likwid/5.0.1 metis/5.1.0 mpich/3.4.2-ofi mvapich2/2.3.6 openblas/0.3.7 openmpi4/4.1.1 pdtoolkit/3.25.1 plasma/2.8.0 py3-numpy/1.19.5 scotch/6.0.6 superlu/5.2.1
----------------------------------------------------------------------------------------- /opt/ohpc/pub/modulefiles -----------------------------------------------------------------------------------------------------------------
EasyBuild/4.6.2 charliecloud/0.15 gnu12/12.2.0 golang/1.20.3 java/8.0_371 libfabric/1.13.0 ohpc papi/5.7.0 singularity/3.7.1 ucx/1.11.2
autotools cmake/3.24.2 gnu9/9.4.0 (L) hwloc/2.7.0 java/20.0.1 (D) magpie/2.5 os prun/2.2 stata/17 valgrind/3.19.0
Where:
D: Default Module
L: Module is loaded
We can now see an (L) icon next to gnu9 to show it’s loaded. Other modules like R that depend on gnu9 now appear.
Take a look at the /opt/ohpc/pub/moduledeps. Load the module with the name of the folder to have their dependant modules appear.
Using modules in your scripts#
Slurm preserves the enviroment you submitted your job in.
If you load a module then submit your script, the module will stay loaded in the running job.
However you are able to include module load statements in your SBATCH script:
#!/bin/bash
#SBATCH --job-name=parallel_test # Job name
#SBATCH --mail-type=END,FAIL # Mail events (NONE, BEGIN, END, FAIL, ALL)
#SBATCH --mail-user=email@lshtm.ac.uk # Where to send mail
#SBATCH --nodes=1 # Run all processes on a single node
#SBATCH --ntasks=16 # Run a single task
#SBATCH --mem=1gb # Total memory limit
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --output=parallel_%j.log # Standard output and error log
date;hostname;pwd
module load R
echo "Running R in parallel on 16 cores"
Rscript Rcode.R
date
Including the module commands in the script is a good idea, so you don’t forget to load/unload modules before you submit.