Content from A shared software stack

Last updated on 2026-10-27 | Edit this page

Overview

Questions

  • Why do you load a module instead of installing a program into your home directory?
  • What does the EESSI init script print, and which part of that printout can differ?

Objectives

  • Describe a shared stack as one curated set of builds, selected with a module.
  • Say what CVMFS fetches, and name the tree /cvmfs/software.eessi.io.
  • Point to the EasyBuild book when the question is how a module was built, and stop there.
  • Read the CPU line from the init script and leave a different CPU name alone.

One copy, many people

If every person compiles their own Python, the disk fills with almost the same files. Nobody can say which copy a paper used. A shared stack is one curated set of builds. You select a build by loading a module. The files stay on a shared file system. Your home directory stays for your own scripts and small inputs.

A cluster serves people from many fields. They need different programs, and often two versions of the same library. They also need builds tuned for the machine, not a binary that was packed for a laptop. Root access is restricted, so a private installer is the wrong tool even before the disk fills up.

Compiling from source, a Conda environment, and a container can each solve one person’s problem. None of those is a way to support the whole machine. A local install is hard to patch for everyone, hard to tune once, and hard to name in a second paper. The module system is how the site hands out one supported copy.

CVMFS fetches the file you use

EESSI is a shared stack of scientific builds, published by a group of European HPC sites so the same software can be loaded on more than one machine. It is distributed with CVMFS.

CVMFS shows a directory tree that is the same on every machine that mounts it. It fetches a file when you first use it. You do not copy the whole stack before you start. The tree for this lesson is /cvmfs/software.eessi.io.

Where a program comes from. The nodes drawn are your script, CVMFS, EESSI, module, and the program.
Where a program comes from. The nodes drawn are your script, CVMFS, EESSI, module, and the program.

Your script asks for a program. The module command points at a build in the EESSI tree. CVMFS supplies the file. You do not see a separate download step.

EasyBuild is a different course

How those builds are produced is not this lesson. EasyBuild is the tool that turns a recipe into the module you load. Read that story in the book at https://hpceb.rgoswami.me/ and in the sources at https://github.com/HaoZeke/what-easybuild-is-doing. This lesson only uses the result.

Names for a stack

On Snellius the site stacks are named by year.

  • 2025 is the production stack and is fully supported.
  • 2024 is the previous production stack and has limited support.
  • 2023 is deprecated and is provided as-is.
  • EESSI is the common stack. It is a different row from the year names.

The command you type is not the same string on every machine. Read the tab for the machine in your welcome note before you assume a year name means one thing everywhere.

Callout

Type along

Follow the tab for the machine you are on. On a cluster the tab loads the stack with module load. In the client container the tab sources the init script, because that container has no module named 2025.

Read the paragraph under the command in your tab.

On the course cluster, module load 2025 loads EESSI 2025.06. The names 2024 and foss/2023a load that same stack, so an older script still starts. On Snellius, module load 2025 selects the 2025 site stack. In the container there is no module named 2025. The init script is the command there:

BASH 

source /cvmfs/software.eessi.io/versions/2025.06/init/lmod/bash

That script loads EESSI/2025.06 and prints three kinds of lines: that the module loaded, which CPU target it selected, and whether it saw a GPU. On one Intel host the lines were:

Module for EESSI/2025.06 loaded successfully
EESSI has selected x86_64/intel/sapphirerapids as the compatible CPU target for EESSI/2025.06
EESSI did not identify an accelerator on the system

The CPU line is an example. Your line may name a different CPU. Read the line. The init script picks the directory. Do not copy a path from someone else’s CPU into your script.

The client is the same repository, with no queue. Use it when you have no cluster login. Skip the download when you are already on a cluster.

The previous EESSI stack is still published. After module purge, module load EESSI/2023.06 switches to it. You can also source /cvmfs/software.eessi.io/versions/2023.06/init/lmod/bash in a new shell. Do not load both stacks in one shell. Purge first. The next episode loads Python from one stack at a time.

Challenge

Where a private copy fails

A lab mate wants to pip install a scientific package into their home directory so the paper has a private copy. Name one problem that causes on a shared machine. Where do you send the question “how was this module built?”

A private copy fills home, drifts away from the copy the next person loads, and cannot be named as one module in two papers. Support cannot patch every home directory. The question about how the module was built goes to the EasyBuild book at https://hpceb.rgoswami.me/, not to a second install in this lesson.

Challenge

Read the CPU line

You sourced the 2025.06 init script. It printed a CPU target. A neighbour’s notes say x86_64/intel/sapphirerapids. Yours names a different CPU. Which line do you keep, and what do you not paste into a job script?

Keep the line your own init script printed. x86_64/intel/sapphirerapids is one host’s example, not a required value. The path under /cvmfs/software.eessi.io/versions/2025.06/ contains that CPU directory. The init script chooses it. Pasting a neighbour’s CPU directory into PATH or into a script points at builds that may not match your machine.

Key Points
  • A shared stack is one supported copy of a program, selected with a module.
  • CVMFS shows /cvmfs/software.eessi.io and fetches a file when you first use it.
  • EasyBuild, and how a module file is produced, is the book at https://hpceb.rgoswami.me/.
  • The init script prints a CPU target. The example x86_64/intel/sapphirerapids can differ.
  • module purge before you switch stacks. Do not load two stacks in one shell.

Content from Finding and loading a module

Last updated on 2026-10-27 | Edit this page

Overview

Questions

  • Which command lists only the modules you can load right now, and which command searches the rest?
  • Which Python module is the EESSI 2025.06 default, and what does python3 --version print?
  • Where do you load QCG-PilotJob if module spider cannot find it in EESSI?

Objectives

  • Use module avail, module spider, module load, module list, module unload, and module purge.
  • Load Python/3.13.5-GCCcore-14.3.0 and read Python 3.13.5.
  • Switch to EESSI 2023.06 only after a purge, and read Python 3.11.5.
  • State that QCG-PilotJob is a site module and is not in the EESSI tree.

Two lists

module avail prints modules you can load in this shell, right now. EESSI is hierarchical. A Python build sits behind the stack module, and often behind a compiler module. Until those are loaded, module avail Python can be empty or short. That does not mean Python is missing.

module spider searches the whole tree. It finds names that module avail hides. module spider Python is the search you want when you know the program and not the compiler.

module help prints the command options. module whatis Python/3.13.5-GCCcore-14.3.0 prints the short description stored in that module file. module list prints what this shell has loaded. ml is the short form of module once the init script has run. ml Python is the same action as module load Python.

Command What it does
module avail Modules you can load right now
module spider Every matching module, including hidden ones
module load Puts a module in this shell
module unload Removes one module
module list Shows what is loaded
module purge Removes all modules
module whatis Prints the module’s short description

One Python from the 2025.06 stack

Load the stack the way your tab shows, then search.

In EESSI 2025.06 the Python modules include:

  • Python/3.12.3-GCCcore-13.3.0
  • Python/3.13.1-GCCcore-14.2.0
  • Python/3.13.5-GCCcore-14.3.0 (the default)

The name has the version and the GCCcore it was built with. Load the default:

BASH 

module load Python/3.13.5-GCCcore-14.3.0
python3 --version

python3 --version prints Python 3.13.5. which python3 prints a path under /cvmfs/software.eessi.io/versions/2025.06/. The CPU directory in the middle of that path is the one the init script chose. It is not /usr/bin/python3.

On Snellius, module load 2025 selects the site 2025 stack. If module spider Python does not list Python/3.13.5-GCCcore-14.3.0, load the newest 3.13 it does list and write that full name in your notes. Do not invent a version.

A faded load, for the stack this course uses:

BASH 

module load Python/________
python3 --version

The module is Python/3.13.5-GCCcore-14.3.0. The version line is Python 3.13.5.

Unload one, or clear the shell

module unload Python/3.13.5-GCCcore-14.3.0 removes that Python. The stack module can stay loaded. module list no longer includes the Python name.

module purge removes every module. module list then reports that no modules are loaded. Purge is the step between stacks.

EESSI 2023.06 has Python/3.11.5-GCCcore-13.2.0. After a purge:

BASH 

module load EESSI/2023.06
module load Python/3.11.5-GCCcore-13.2.0
python3 --version

python3 --version prints Python 3.11.5. Do not load EESSI/2025.06 and EESSI/2023.06 in one shell. Do not source the 2025.06 init script and then module load 2025 on top of it. Two stacks in one shell is how two Pythons end up on PATH.

Callout

Conda stays separate

A Conda environment and a loaded module often conflict. The site stack is the supported copy. Do not mix a Conda activate with these modules in the same shell.

QCG-PilotJob is not in EESSI

module spider QCG-PilotJob in an EESSI-only shell does not find it. The tool is not part of the 2025.06 release. Do not spend the episode walking the CVMFS tree looking for it.

On the clusters it is a site module. The load line is the tab, not a path you guess.

Course scripts name QCG-PilotJob/0.14.1-gfbf-2024a after the stack load. If spider prints that name, load it. If spider prints a different full name, load the name it prints. The container will still not have it. Later episodes that need the pilot use the cluster.

Caution

Login node

python3 --version and module list are fine on the login node. A long Python script is not. The login node is shared. Send the long run to the queue.

Challenge

Predict the version lines

Write down the two version lines before you run the block. Use a shell you are allowed to purge.

In the container, or on any machine where /cvmfs/software.eessi.io is mounted:

BASH 

module purge
source /cvmfs/software.eessi.io/versions/2025.06/init/lmod/bash
module load Python/3.13.5-GCCcore-14.3.0
python3 --version
module purge
module load EESSI/2023.06
module load Python/3.11.5-GCCcore-13.2.0
python3 --version

On a cluster, do not source the init script in a shell where you also ran module load 2025. Use the tab’s load command for the 2025 stack, check python3 --version, purge, and only then try EESSI/2023.06. If that module name does not exist on Snellius, stop. Do not load a second stack on top of the first.

In the EESSI client the two python3 --version lines are:

Python 3.13.5
Python 3.11.5

The first comes from Python/3.13.5-GCCcore-14.3.0 on EESSI 2025.06. The second comes from Python/3.11.5-GCCcore-13.2.0 on EESSI 2023.06. module purge between them is required. which python3 for the first load starts with /cvmfs/software.eessi.io/versions/2025.06/.

On Snellius, if the 3.13.5 module name is absent, the version line is the one for the module you actually loaded. Record that name. A missing EESSI/2023.06 is a stop, not a reason to skip the purge.

If the init script stops because a variable is unset, run set +u before source and set -u afterwards. The two version lines do not change.

Challenge

List, unload, purge

Load the 2025.06 default Python. Run module list. Unload that Python module and run module list again. Purge and run module list a third time. What happens to the Python name?

After the load, module list includes Python/3.13.5-GCCcore-14.3.0. Other modules may be there too, because loading Python also loads the libraries it needs. That is expected.

After module unload Python/3.13.5-GCCcore-14.3.0, that name is gone. The stack module can still be listed.

After module purge, module list reports that no modules are loaded. The next python3 is no longer the stack copy unless something else on PATH provides one.

Challenge

Search for a module that is not in the stack

Run module spider QCG-PilotJob in a shell that has only EESSI loaded. Then look at the tab above and say where the tool actually comes from.

Spider reports that it cannot find QCG-PilotJob in the EESSI tree. That result is correct. The tool is not in the 2025.06 release.

On a cluster, load it the way the tab shows: the stack name first (module load 2025 on Snellius, module load 2024 on the course cluster), then module load QCG-PilotJob. module list then includes QCG-PilotJob. The full name in the course scripts is QCG-PilotJob/0.14.1-gfbf-2024a when spider lists that name.

The container has no site module to add. A failed spider search there does not mean you should install a private copy during this lesson.

Key Points
  • module avail is the current level. module spider searches the rest.
  • module load selects. module unload removes one. module purge clears the shell.
  • EESSI 2025.06 default Python is Python/3.13.5-GCCcore-14.3.0, and python3 --version prints Python 3.13.5.
  • EESSI 2023.06 has Python/3.11.5-GCCcore-13.2.0. Purge before you load it.
  • QCG-PilotJob is a site module. Spider does not find it in EESSI.

Content from The EESSI client container

Last updated on 2026-10-27 | Edit this page

Overview

Questions

  • How do you get the EESSI 2025.06 stack when you have no cluster login?
  • What do $EESSI_VERSION and $EESSI_CVMFS_REPO print, and what does the CPU line mean?
  • Which commands are missing inside the client?

Objectives

  • Start the EESSI client with Apptainer and source the 2025.06 init script.
  • Read 2025.06 from $EESSI_VERSION and /cvmfs/software.eessi.io from $EESSI_CVMFS_REPO.
  • Treat x86_64/intel/sapphirerapids as one example CPU line, not as your required path.
  • Show that sbatch is absent and that python3 --version still prints Python 3.13.5.

The same tree, no queue

The cluster episodes use a module command the site provides. When you have no login, the EESSI client container mounts the same CVMFS repository and gives you the same init script.

The client is an Apptainer container. Apptainer 1.0 or newer is required, with --fusemount support. The mount makes /cvmfs/software.eessi.io exist inside the container. That is why the init script path works. The image is docker://ghcr.io/eessi/client:rocky8.

There is no Slurm inside the container. sbatch and squeue are not installed. hostname prints the container’s own name, not a cluster node. Use the container for module and python3. Use Snellius or the course cluster when the work must go through a queue.

The first launch downloads the image and can take a few minutes. Later launches are shorter.

Start the client

The directories under $HOME/eessi-work hold the CVMFS state and the home directory you see inside the container. The bind mounts give the container somewhere to write that state. You create them once.

Callout

Type along

Run the tab on a machine where Apptainer works. If you are already on Snellius or the course cluster, read the tab and do not start a second copy of the stack in this shell.

The Snellius and course-cluster tabs say you do not need the container there. The remaining tab is the launch. Inside the container, the next command is the init script:

BASH 

source /cvmfs/software.eessi.io/versions/2025.06/init/lmod/bash

The script loads EESSI/2025.06. It prints that the module loaded, which CPU it selected, and whether it saw a GPU. One host printed:

Module for EESSI/2025.06 loaded successfully
EESSI has selected x86_64/intel/sapphirerapids as the compatible CPU target for EESSI/2025.06
EESSI did not identify an accelerator on the system

x86_64/intel/sapphirerapids is an example. A laptop, a different server, or another container host can print a different CPU. Read your line. Do not paste this example into PATH.

Two variables that stay put

The CPU directory can change. Two variables do not:

BASH 

printf '%s\n' "$EESSI_VERSION"
printf '%s\n' "$EESSI_CVMFS_REPO"

$EESSI_VERSION prints 2025.06. $EESSI_CVMFS_REPO prints /cvmfs/software.eessi.io.

If either line is empty, the init script did not run in this shell. Source it again. Do not also module load 2025 here. The container has no module by that name, and stacking a second init on top of the first is the same mistake as loading two stacks.

Then load the default Python from the previous episode:

BASH 

module load Python/3.13.5-GCCcore-14.3.0
python3 --version

python3 --version prints Python 3.13.5. which python3 starts with /cvmfs/software.eessi.io/versions/2025.06/.

Caution

Login node

This container is not a login node, and it is not a place to avoid the queue by running a long job. python3 --version is the check. A long script waits until you have sbatch on a cluster.

Challenge

Predict the two variables

Source the 2025.06 init script in the client. Before you print them, write down $EESSI_VERSION and $EESSI_CVMFS_REPO. Then run:

BASH 

printf '%s\n' "$EESSI_VERSION"
printf '%s\n' "$EESSI_CVMFS_REPO"
2025.06
/cvmfs/software.eessi.io

The first line is the stack the init script loaded. The second is the CVMFS repository, not a directory under your home. An empty line means the init script has not been sourced in this shell.

Challenge

Your CPU line, not the example

Copy the CPU line the init script printed into your notes. Does it have to be x86_64/intel/sapphirerapids? What would go wrong if a job script hardcoded that directory?

It does not have to be x86_64/intel/sapphirerapids. That string is one host’s example. Your line should contain a CPU target under x86_64/ (or another architecture the script supports) and the words that name the compatible CPU.

A hardcoded sapphirerapids path fails on a machine whose init script selected a different CPU. The builds in that directory match the CPU that was detected, not the CPU written in someone else’s notes. Let the init script select the directory.

Challenge

No batch command, same Python

In the same container shell, after the init script:

BASH 

command -v sbatch || printf 'no-sbatch\n'
module load Python/3.13.5-GCCcore-14.3.0
python3 --version

What do the two output lines mean?

no-sbatch
Python 3.13.5

command -v sbatch prints nothing and returns a failure status, so the shell prints no-sbatch. The client has no Slurm. squeue is missing for the same reason.

Python 3.13.5 is the EESSI 2025.06 default module, the same string as on a cluster that has Python/3.13.5-GCCcore-14.3.0. The stack matches. The queue does not. Submit jobs on Snellius or the course cluster, not in this shell.

Key Points
  • The EESSI client is an Apptainer container that mounts /cvmfs/software.eessi.io.
  • The init script is source /cvmfs/software.eessi.io/versions/2025.06/init/lmod/bash.
  • $EESSI_VERSION prints 2025.06. $EESSI_CVMFS_REPO prints /cvmfs/software.eessi.io.
  • The CPU line x86_64/intel/sapphirerapids is an example and may differ.
  • The container has no sbatch. python3 --version still prints Python 3.13.5.