Skip to content

The Module System

Software on the cluster is managed via Environment Modules, which let you load and unload specific versions of compilers and MPI libraries without conflicts. When you first log in, your environment is minimal by design. 

# See all available software
module avail

# Load a module
module load gcc/13
module load mpi/mpich-x86_64

# See what is currently loaded
module list

# Unload a specific module
module unload gcc/13

# Start fresh — unload everything
module purge

What is actually available

The module tree is small and deliberately so — it covers compilers and MPI. Everything else (Python, Mathematica, your own code) is handled differently.

Module Provides
gcc/13, gcc/14, gcc/15 GCC toolsets (gcc, g++, gfortran) from /opt/rh/gcc-toolset-*
mpi/mpich-x86_64 MPICH
mpi/openmpi-x86_64 OpenMPI

Without any module loaded you get the system compiler, GCC 11.5. There is no module for Python (see Software → Python) and none for Mathematica (see Software → Mathematica) — both are available without loading anything.

⚠️ module does not exist in batch jobs until you enable it

This is the single most common way a working script silently produces wrong results on this cluster.

A Slurm batch script runs as a non-login, non-interactive shell. That kind of shell does not read /etc/profile.d/, which is where the module shell function is defined. So in a plain #!/bin/bash batch script:

/var/spool/slurm/slurmd/job1012527/slurm_script: line 14: module: command not found

The danger is that this is not a fatal error. module load gcc/15 prints that message to stderr and the script keeps going — with the system GCC 11.5 instead of the compiler you asked for. Your job "succeeds", your code is built with the wrong toolchain, and nothing obviously went wrong.

The fix

Source the modules initialisation script before your first module command: 

#!/bin/bash
#SBATCH --job-name=my_job
# ... other directives ...

# REQUIRED in every batch script that uses modules
source /etc/profile.d/modules.sh

module purge
module load gcc/15

Alternatively, make the script a login shell with #!/bin/bash -l, which causes /etc/profile.d/ to be read for you: 

#!/bin/bash -l
#SBATCH --job-name=my_job

module purge
module load gcc/15

Both work. This guide uses source /etc/profile.d/modules.sh throughout, because it is explicit and keeps working if someone later changes the shebang.

💡 Always verify the compiler you actually got.

Since a failed module load is not fatal, print the version in your job log and check it once. It costs nothing and catches the problem immediately: 

echo "Using: $(gcc --version | head -1)"
echo "From:  $(which gcc)"

A correctly loaded gcc/15 reports 15.2.1 from /opt/rh/gcc-toolset-15/root/usr/bin/gcc. If you see 11.5.0 from /usr/bin/gcc, your module load did not take effect.

💡 Modules do not travel from the login node to your job.

Compute nodes start with a clean environment. Modules you loaded interactively on the login node are not inherited by your batch jobs. Always include the source line and your module load commands explicitly in every Slurm script.