Load software modules¶
Note: this page contains some example output from the module command
that may not be up-to-date, it is meant for illustration purposes only.
Default module stack¶
A new version of the software stack is released every year in late summer. Two generations of the stack are maintained/available, but it is highly recommended to switch to the latest software stack during the months following its release.
Right after logging in, before loading anything, module avail already shows two
sections: the available stack years, and a set of generic/vendor software that's always
available regardless of which stack (or none) you've loaded:
[<netid>@login01 ~]$ module avail
--------------------------------------------------------- Global Aliases ---------------------------------------------------------
miniconda3 -> miniforge3/25.11.0 miniconda3/4.12.0 -> miniforge3/25.11.0
---------------------------------------------------- /apps/noarch/modulefiles ----------------------------------------------------
2025 2026
--------------------------------------------------- /apps/generic/modulefiles ----------------------------------------------------
abaqus/2022 cuda/11.6 (D) fds/6.9.1 intel/oneapi nvhpc/23.5
abaqus/2024 (D) cuda/11.7 febio/studio-2.6 intel_mpi/2021.18 nvhpc/25.7 (D)
ams/2025.102 cuda/12.1 febio/2.6 julia/1.11.6 nxnastran/2025.1
ams/2026.102 (D) cuda/12.5 febio/4.11 (D) ls-dyna/13.0.1 paraview/5.9.1
ansys/2023R2 (D) cuda/12.9 feko/2022 mathematica/13.0.0 slurm/current
ansys/2024R1 diana/10.6 feko/2022.2.1 (D) matlab/R2021b smokeview/6.9.1
ansys/2024R2 diana/10.9 gurobi/10.0.3 matlab/R2024a tecplot/2023r1
ansys/2025R2 diana/10.10 (D) gurobi/11.0.1 (D) matlab/R2024b-ParServ vasp/5.4.4-pl2
compose/2023 diana/11.1 gurobi/12.0.0 matlab/R2024b (D) vasp/6.6.1 (D)
compose/2023.1 (D) edem/2022.2 (D) intel/oneapi_2022.3 (D) mechanical-solvers/2022.2 (D) yambo/5.2.3
comsol/5.6 edem/2023 intel/oneapi_2024.0 mechanical-solvers/2023
comsol/6.1 edem/2024.1 intel/oneapi_2026.1 miniforge3/25.11.0
comsol/6.2 (D) edem/2025 intel/oneapi-all nvhpc/22.3
A software stack year can be loaded as follows:
Choosing an architecture: cpu, gpu, and friends¶
Since the 2026 stack, loading the year alone is not enough to get the bulk of the
software stack. It only reveals a new selector layer at /apps/2026/modulefiles:
[<netid>@login01 ~]$ module load 2026
[<netid>@login01 ~]$ module avail
[... noarch/generic sections as above, with 2026 now marked (L) ...]
----------------------------------------------------- /apps/2026/modulefiles -----------------------------------------------------
compilers cpu-avx512 cpu gpu-avx512 gpu visual
You then load one of these on top, e.g. module load cpu. Since module load accepts
multiple names on one line (loaded left to right), this is normally written as a single
command:
or, for GPU work:
This is the key change from earlier stacks: which architecture-specific software tree you
get is now an explicit choice you make with cpu/gpu, rather than something that
was silently auto-detected from which node you happened to be logged into. You can make
this choice from any node, including a login node without a GPU card — loading
2026 gpu there gives you the same software tree (and, for Python packages, GPU-aware
libraries) that the actual GPU compute nodes use.
The six choices currently available under 2026:
| module | targets | purpose |
|---|---|---|
cpu |
x86-64-v3 |
General-purpose software for compute nodes, built for a portable CPU baseline. Works on compute-p1 and compute-p2. |
cpu-avx512 |
x86-64-v4 (needs avx512f/bw/cd/dq/vl) |
Same software as cpu, but built to use AVX-512. Works on both compute-p1 and compute-p2 — also compute-p1's Cascade Lake CPUs support the baseline AVX-512 instruction set. |
gpu |
x86-64-v3 |
Software for GPU nodes, portable baseline (this is what all the GPU-related howtos on this site use by default). Works on gpu-v100 and gpu-a100. |
gpu-avx512 |
x86-64-v4 |
Same as gpu, built with AVX-512. Works on gpu-a100 only — gpu-v100's AMD EPYC CPUs have no AVX-512 support at all, so a gpu-avx512 binary would fail with an illegal-instruction error there. |
compilers |
— | A minimal environment for building your own software, without a full application stack. |
visual |
— | For the visualization/interactive nodes. Unlike the others, this one is also available under the 2025 stack. |
The AVX-512 split is about CPU generation, not old vs. new nodes
It's tempting to assume cpu-avx512/gpu-avx512 are for DelftBlue's newer
(Phase 2, 2024) nodes and plain cpu/gpu for the older (Phase 1, 2022) ones — but
that's not quite right. Verified via lscpu on each partition: compute-p1
(Phase 1, Cascade Lake) already has the baseline AVX-512 instruction set that
cpu-avx512 targets, so it works there too. The real split that matters is
CPU vendor on the GPU side: gpu-v100's AMD EPYC CPUs have no AVX-512 at all,
while gpu-a100's Intel CPUs do — so gpu-avx512 is effectively gpu-a100-only.
compute-p2/gpu-a100 (Sapphire Rapids) do have a noticeably richer instruction
set beyond the x86-64-v4 baseline (avx512_bf16, avx512_fp16, Intel AMX for
matrix/AI workloads) that compute-p1 lacks, but the module stack doesn't offer a
separate tier targeting those specifically — cpu-avx512/gpu-avx512 stop at the
standard x86-64-v4 level. Software wanting to exploit AMX/bf16/fp16 directly would
need to be built for it specifically (e.g. via Spack).
Different node types may still offer different software!
Choosing cpu or gpu is now an explicit decision, not something tied to which
physical node you're on — but the concrete packages and versions available within a
given choice can still differ from what's installed on a specific node (e.g. a
particular cudnn/nccl version tied to actual GPU hardware). Don't assume every
package with exactly the same version is available identically everywhere; use
module avail (or module spider <package>) to check.
Within a chosen architecture, you'll again see two kinds of modules:
- generic modules from
/apps/generic/modulefiles, available regardless ofcpu/gpuchoice (e.g.cuda,matlab,comsol); - modules specific to that architecture, e.g.
/apps/2026/cpu/lmod/linux-almalinux9-x86_64/Coreforcpu, or/apps/2026/gpu/lmod/linux-almalinux9-x86_64/Coreforgpu.
Here is a (truncated) excerpt of what module avail shows after module load 2026 cpu:
[<netid>@login01 ~]$ module load 2026 cpu
[<netid>@login01 ~]$ module avail
----------------------------------------------------- /apps/2026/modulefiles -----------------------------------------------------
compilers cpu-avx512 cpu (L) gpu-avx512 gpu visual
---------------------------------------- /apps/2026/cpu/lmod/linux-almalinux9-x86_64/Core ----------------------------------------
apr-util/1.6.3 nano/8.7 r-data-table/1.17.8
apr/1.7.5 nasm/2.16.03 r-dbi/1.2.3
arrow/18.0.0 ncurses/6.6 r-dbplyr/2.5.0
autoconf-archive/2024.10.16 ncview/2.1.9 r-digest/0.6.37
autoconf/2.72 netcdf-c/4.9.3 r-dplyr/1.2.0
automake/1.18.1 netcdf-cxx/4.2 r-dtplyr/1.3.1
bash/5.3 netcdf-fortran/4.6.2-tyxnqox r-e1071/1.7-14
bdftopcf/1.1.1 nghttp2/1.67.1 r-evaluate/0.24.0
berkeley-db/18.1.40 ninja/1.13.2 r-fansi/1.0.6
binutils/2.43.1 nlohmann-json/3.12.0 r-farver/2.1.2
bison/3.8.2 numactl/2.0.19 r-fastmap/1.2.0
boost/1.90.0 openblas/0.3.30_threads_openmp (D) r-fontawesome/0.5.2
cmake/3.31.11 openmpi/5.0.10 r-forcats/1.0.0
curl/8.18.0 openssl/3.6.1 r-ggplot2/3.5.1
gcc-runtime/13.4.0 py-numpy/2.4.3 (D) r-matrix/1.7-0
git/2.53.0 py-pandas/3.0.1 r-rcpp/1.1.1
gsl/2.8 py-scipy/1.17.1 r-tidyverse/2.0.0
hdf5/1.14.3 py-torch/2.10.0 r/4.5.2
...
(the full listing runs to several hundred packages, including a large set of py-*
Python and r-* R packages — run module avail yourself for the complete, current list)
Loading modules hierarchically¶
Modules need to be loaded with the right module paths. This system is based on lmod, which is organized hierarchically. This means that the modules you see depend on the ones you have already loaded: for example, if you don't load openmpi you don't see hdf5, etc. To find modules in the hierarchy, you can use the module spider command.
For example, if you are looking for the package trilinos, you can type the following:
[<netid>@login01 ~]$ module load 2026 cpu
[<netid>@login01 ~]$ module spider trilinos
-------------------------------------------------------------------------------------------------------------------------------
trilinos:
-------------------------------------------------------------------------------------------------------------------------------
Versions:
trilinos/16.0.0
trilinos/16.2.0
-------------------------------------------------------------------------------------------------------------------------------
For detailed information about a specific "trilinos" package (including how to load the modules) use the module's full name.
For example:
$ module spider trilinos/16.2.0
trilinos doesn't show up in the plain cpu listing above because it depends on openmpi. Loading openmpi first opens another sub-set of available modules that depend on it:
[<netid>@login01 ~]$ module load openmpi
[<netid>@login01 ~]$ module avail
---------------------------- /apps/2026/cpu/lmod/linux-almalinux9-x86_64/openmpi/5.0.10-zjhzcpq/Core -----------------------------
adios2/2.11.0 mumps/5.8.2 openfoam-org/12 (D)
conduit/0.9.5 ncl/6.6.2 openfoam/2512
cp2k/2026.1 netcdf-c/4.9.3 (D) parallel-netcdf/1.14.1
dbcsr/2.9.1 netcdf-fortran/4.6.2-f2xjuas parmetis/4.0.3
esmf/8.2.0 netlib-scalapack/2.2.2 petsc/3.24.5
fftw/3.3.10_openmp_False opencoarrays/2.10.2 plumed/2.10.0
fftw/3.3.10_openmp_True (D) openfast/4.2.0 py-mpi4py/4.1.1
gromacs/2025.0 openfoam-org/7 scotch/7.0.10 (D)
hdf5/1.14.3 (D) openfoam-org/8 superlu-dist/9.2.1_openmp_True
hypre/3.1.0 openfoam-org/9 trilinos/16.2.0
lammps/20250722.3 openfoam-org/10 wannier90/3.1.0 (D)
libcatalyst/2.0.0 openfoam-org/11 wrf/4.7.1
So, to load trilinos, all you need to do now is:
[<netid>@login01 ~]$ module load 2026 cpu
[<netid>@login01 ~]$ module load openmpi
[<netid>@login01 ~]$ module load trilinos
[<netid>@login01 ~]$ module list
Currently Loaded Modules:
1) 2026 2) cpu 3) openmpi/5.0.10 4) trilinos/16.2.0
Note that, unlike some older stacks, loading trilinos here doesn't cascade into a long chain of separate "Autoloading ..." dependency modules — its dependencies are built into the module itself. Don't assume every package behaves the same way; some may still autoload further modules, in which case they'll be listed here too.
You can use module unload to unload the loaded module, and module show to display module information.
Environment variables¶
Finally, most modules from the current software stack set their own environment variable of the format $MODULENAME_ROOT. For example, for trilinos:
[<netid>@login01 ~]$ echo $TRILINOS_ROOT
/apps/2026/cpu/software/linux-x86_64_v3/trilinos-16.2.0-fkp2upj2nimlgsemlowerqjiaqnq3wvi
If you cd to the above directory, you will find all the usual suspects sub-folders, such as bin, include, and lib. Note the linux-x86_64_v3 in the path — this confirms the cpu flavor is built against a generic/portable x86-64 baseline (as opposed to a specific CPU codename), consistent with cpu-avx512 being built for a newer instruction-set tier on top of it.
My module does not seem to set $MODULENAME_ROOT. Help!
Some modules might set different environment variables, if a more "standard" variable exists and is commonly recognized. For example, the cuda/12.9 module sets $CUDA_PATH, $CUDA_HOME, and $CUDA_ROOT. Other examples are intel/oneapi-all, and intel-mkl modules that set the $MKLROOT variable.
Luckily, you can always find which variables are set by issuing module show command:
[<netid>@login01 ~]$ module show cuda/12.9
-------------------------------------------------------------------------------------------------------------------------------
/apps/generic/modulefiles/cuda/12.9.lua:
-------------------------------------------------------------------------------------------------------------------------------
conflict("cuda")
whatis("CUDA 12.9")
whatis("NVIDIA CUDA Toolkit provides a development environment for creating high performance GPU-accelerated applications.")
setenv("CUDA_PATH","/beegfs/apps/generic/cuda/12.9")
setenv("CUDA_HOME","/beegfs/apps/generic/cuda/12.9")
setenv("CUDA_ROOT","/beegfs/apps/generic/cuda/12.9")
prepend_path("PATH","/beegfs/apps/generic/cuda/12.9/bin")
prepend_path("CPATH","/beegfs/apps/generic/cuda/12.9/include")
prepend_path("LIBRARY_PATH","/beegfs/apps/generic/cuda/12.9/lib64")
prepend_path("LD_LIBRARY_PATH","/beegfs/apps/generic/cuda/12.9/lib64")
Same procedure applies to all modules. Note that cuda itself lives under /apps/generic/modulefiles — it's a generic module available regardless of whether you've loaded cpu or gpu.
Placing your standard modules to .bashrc
TODO - Use the intended functionality for this (using $HOME/.module, see man module for details)
In order to make your life easier, you can place all your typically used modules to the /home/<netid>/.bashrc file. These modules will then be loaded automatically every time you log in. Let's open the .bashrc file with vi:
This is the default contents of the file, keep this as is:
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
then
PATH="$HOME/.local/bin:$HOME/bin:$PATH"
fi
export PATH
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
After the last line, we can add any bash command that we want to be executed upon login. For example, I would like to enable the DelftBlue software stack for compute nodes, load the Intel compilers suite, and then load cmake and some Python modules:
# Load DelftBlue software stack modules (compute-node flavor):
module load 2026 cpu
# Load DelftBlue software stack Intel compilers:
module load intel/oneapi-all
# Load DelftBlue software stack Python for compute nodes:
module load python
module load py-numpy
module load py-scipy
module load py-matplotlib
# Load cmake:
module load cmake
Upon the next login, these modules (and their dependencies) would be loaded automatically, similar to the module list example under Loading modules hierarchically above — just with python, py-numpy, py-scipy, py-matplotlib, and cmake in place of openmpi/trilinos.