Summary and Schedule

This lesson is a one-day introduction to a shared supercomputer. You will log in, load software from the EESSI stack, submit Slurm jobs, move data without drowning the file system, run many small tasks, and take a first look at timing and scaling.

This lesson has six episodes. Each one is about half an hour of teaching plus a short exercise. The slide decks for the SURF course sit beside it. The instructor notes say which deck matches which episode.

Prerequisite

You can open a terminal and move around a file system
You can edit a plain text file
You have a Snellius account, a seat on the course cluster, or the EESSI client container from the setup page

The course cluster is a small Magic Castle cluster on SURF Research Cloud. It has the same kinds of parts as Snellius: a login node, Slurm, a shared file system, and the EESSI software stack. The numbers are smaller. Commands you practice there are the commands you will use on Snellius, with a shorter resource request.

If you cannot reach either machine today, every episode has a fallback you can run in the EESSI client container. That container mounts the same software repository the cluster uses. It does not give you a batch queue. You still run the program the job would have run.

Callout

The login node is shared. You prepare work there. You do not run the long computation there.

Setup Instructions

Download files required for the lesson

00h 00m

1. What a supercomputer is

What is different about a supercomputer and the computer on your desk?
How do you log in to Snellius, and how is the course cluster different?
:::

00h 45m

2. Software from a shared stack

Why do you load software instead of installing it into your home directory?
How do you get the same Python on the cluster and in a container?
:::

01h 35m

3. Submitting a job

How do you ask Slurm for time and cores without starting the work on the login node?
What does a job array change, compared with four separate scripts?
:::

02h 35m

4. Files and moving data

Which directory is for a running job, and which one is for a file you still need next month?
Why does a directory of tiny files travel badly?
:::

03h 25m

5. Many small tasks

Why is one Slurm job per tiny task a poor plan?
What does a pilot job keep hold of, while it runs the tasks?
:::

04h 15m

6. Timing and scaling

What does a single timing tell you, and what does it fail to tell you?
When does adding cores stop helping?
:::

05h 00m

Finish

The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor.

You need a terminal and one of the three machines below. You do not need all three.

Snellius

Snellius is the Dutch national supercomputer. SURF sends the account mail after your project has a login. The public description of the machine is at https://www.surf.nl/en/services/compute/snellius-the-national-supercomputer.

BASH

ssh YOUR_LOGIN@snellius.surf.nl

Sign in to the SURF user portal before the first SSH login. If the network you are on is not trusted, the welcome mail names a door node. Use that host instead of snellius.surf.nl.

A browser session through Open OnDemand is still a login node. Do not start the long run there.

The course cluster

The course cluster is a Magic Castle workspace on SURF Research Cloud. The template is https://github.com/ComputeCanada/magic_castle. Your trainer sends a setup link. That link sets your password. The welcome note has the address, written here as MANAGER.

BASH

ssh YOUR_LOGIN@MANAGER

There is one login node. module load 2025 selects EESSI 2025.06. module load 2024 selects that same stack and is the one you load before QCG-PilotJob. There is no CUA account and no project budget on this cluster.

The EESSI client, when you have no cluster

The software episodes also run in the EESSI client container. Access is documented at https://www.eessi.io/isc26-tutorial/getting-access/ and day-to-day use at https://www.eessi.io/isc26-tutorial/usage/.

You need Apptainer 1.0 or newer, with --fusemount support. This shell is the short form of the client script on that page. It mounts the same repository the cluster uses. It does not give you Slurm.

BASH

mkdir -p "$HOME/eessi-work/var-lib-cvmfs" "$HOME/eessi-work/var-run-cvmfs" "$HOME/eessi-work/home"
export APPTAINER_BIND="$HOME/eessi-work/var-run-cvmfs:/var/run/cvmfs,$HOME/eessi-work/var-lib-cvmfs:/var/lib/cvmfs"
export APPTAINER_HOME="$HOME/eessi-work/home:/home/$USER"
apptainer shell --fusemount "container:cvmfs2 software.eessi.io /cvmfs/software.eessi.io" docker://ghcr.io/eessi/client:rocky8

Inside the container:

BASH

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

python3 --version prints Python 3.13.5. The first launch downloads the image and can take a few minutes. Later launches are shorter.

Callout

The container has no sbatch and no squeue. Use it for the software episode and for pi_one.py. Use Snellius or the course cluster for the queue.

Files from this lesson

The batch scripts and the pi program are in episodes/files/. Copy pi_one.py into the directory you submit from, or submit from episodes/files after you have cloned the lesson.