The Lmod module system¶

Arrhenius uses the Lmod module system to make installed software available and manage the end user environment in a consistent and convenient way from the command line. Invoking the special module help command will present a brief but comprehensive help text on how to use the module command. Also, here you can read about how Lmod abbreviates <action>, while the command itself can also be shortened to ml.

The basic schema for module system usage is...

module <action> <subject>

The primary purpose of the module system is to modify the user environment variables such that software becomes available on search paths and settings are implemented controlling this software. The <action> argument is a verb denoting what should be done with <subject>, which would typically be a named module in most day to day use.

Using the module system boils down to invoking the module command with arguments on the command line or in a script (any script, including batch job scripts).

These are the basic module command invocations which cover most usage.

`<action>`	Abbreviation	Function
`avail`	`av`	list modules within your active hierarchy
`spider`	`spi`	searches the entire module tree
`load`	Not needed	adding software environment
`unload`	`-`	removing software environment
`list`	Not needed	lists loaded modules
`show`		list what parameters, pathes, variables are set

For instance, invoking module avail buildenv, ml av buildenv will list all modules available on the system containing the string buildenv. This search function is character case insensitive.

Skipping the search string to module avail lists all modules available on the configured module search paths. Choosing one of them, e.g. buildenv-intel/2025b-eb, we can make the indicated software environment accessible to us with module load buildenv-intel/2025b-eb.

Assuming a successful loading, the module should be listed as loaded when invoking a module list, ml.

Reversing the environment changes implemented by the module load <module_name>, ml <module_name> command is done with a module unload <module_name>, ml -<module_name>.

Caution

In traditional Cray environments using module.tcl, you typically had to use the swap command to switch from one compiler wrapper to another. With Lmod, this is no longer necessary. Simply loading the desired compiler module is sufficient, as Lmod automatically resolves and replaces conflicting compiler modules.

GPU and CPU modules¶

The machine CPU architecture on Arrhenius is fundamentally different between GPU-equipped nodes and the CPU-only nodes, where the former is an ARM-based architecture, and the latter is an x86_64-based architecture. As a consequence, software built for one part of the machine is not usable on the other. This is reflected both in software installation paths and how compatible modules are presented via the module system. For instance

$ module avail

---------------------------------------------------------------------------------------- CPU partition (epyc9005) modules ----------------------------------------------------------------------------------------
   buildenv-gcc/recommendation (D)    buildenv-intel/recommendation (D)    buildtool-easybuild/5.2.1-hpca3ef7d197        CMake/3.31.11-bdist        Ninja/recommendation    (D)    PatchELF/0.15.5-bdist
   buildenv-gcc/2025b-eb              buildenv-intel/2023a-eb              CMake/recommendation                   (D)    CMake/4.3.2-bdist          Ninja/1.13.2-bdist
   buildenv-gcc/2026.03               buildenv-intel/2025b-eb              CMake/3.29.7-bdist                            Miniforge/26.1.1-3-hpc1    PatchELF/recommendation (D)

------------------------------------------------------------------------------------------ GPU partition (h200) modules ------------------------------------------------------------------------------------------
   GPU/buildenv-gcccuda/recommendation (D)    GPU/buildenv-nvhpc/25.9-cu13.0                    GPU/CMake/3.29.7-bdist     GPU/Ninja/recommendation    (D)    GPU/PatchELF/0.15.5-bdist
   GPU/buildenv-gcccuda/2026.03-cu13.0        GPU/buildtool-easybuild/5.2.1-hpca3ef7d197        GPU/CMake/3.31.11-bdist    GPU/Ninja/1.13.2-bdist
   GPU/buildenv-nvhpc/recommendation   (D)    GPU/CMake/recommendation                   (D)    GPU/CMake/4.3.1-bdist      GPU/PatchELF/recommendation (D)

  Where:
   D:  Default Module

Modules having names prefixed by a GPU/ string are exclusively usable on the GPU partition, while modules lacking this prefix are usable only on the CPU partition. Apart from this prefix string, you may well find identically named modules available for both the GPU partition and the CPU partition, very likely serving the identical software environment in the different contexts.