Modules on Isambard 3 are bare-bones — almost no research software is available through module avail. Their main value is loading the system compiler (gcc-native) when you want to compile your own code.

Containers are orthogonal to the others: a container can wrap a conda or Spack environment and gives access to package managers like apt or nix that are otherwise unavailable on a shared HPC system.

# What is currently loaded?
module list

# Reset to system defaults --- good habit at the top of a job script
module reset

# Browse everything available
module avail

# Search for a specific tool
module avail python
module avail gcc

# Load a module (one of the few tools available this way)
module load brics/emacs

# Unload one module
module unload brics/emacs

Compiling your own code? PrgEnv-gnu loads the GNU compiler toolchain (gcc, g++, gfortran) and the Cray-wrapped MPI library. It is used in later sections whenever C or Fortran code is compiled. Almost everything else you need will come from mamba instead.

Stretch: try module avail and search for a tool you already use.

Which of these have you used on a remote system?

• Copy and paste commands from a tutorial / Stack Overflow
• brew (Homebrew)
• mise
• pip directly into the system Python
• conda or mamba
• pixi
• modules
• Spack
• Something else entirely

cd bootstrap && install/dotfiles.sh install
# make dotfiles active immediately
source ~/.bashrc

The script symlinks .bashrc, .bash_profile, .zshrc, and .zshenv from bootstrap/dotfiles/ into $HOME, and symlinks ~/.config to bootstrap/dotfiles/.config/. Any existing file or directory is backed up as <name>.bak first.

Why bother? Isambard 3 has a shared home directory across both its x86_64 and Arm (aarch64) login nodes. The dotfiles detect the current architecture at login (uname -sm) and route software installations into an arch-specific prefix:

~/.local/opt/Linux-aarch64/   ← used when logged into an Arm node
~/.local/opt/Linux-x86_64/   ← used when logged into an x86_64 node

~/.config is also symlinked so that tool configs (e.g. pixi) live inside the repo and are version-controlled.

Skip this step if you already have a .bashrc you are happy with.

All bootstrap scripts are in the bootstrap/ subdirectory:

# Install VS Code CLI (skip if already done in pre-workshop setup)
install/code.sh install

# Install miniforge (mamba + conda, using conda-forge by default)
install/mamba.sh install

# Install a curated set of command-line tools into a "system" conda env
NAME=system install/mamba-env.sh install

After mamba.sh install, open a new shell (or run source ~/.bashrc) so that mamba is on your path.

# Verify
mamba --version
mamba env list

Pixi is a newer Rust-based package manager from the conda-forge ecosystem. It manages environments per project rather than globally. This workshop repo uses pixi + direnv internally.

Beginners — just run this once and you are done:

cd gw4-isambard-3-practical-workshop-2026
direnv allow          # activates the pixi env automatically every time you cd here

When you enter the repo directory, your shell will use the project environment automatically. You do not need to understand pixi to follow today’s exercises.

Advanced users — want full control over your own environment?

Ignore the direnv allow prompt. Two conda environment*.yml files are committed at the repo root. Use -n to give the environment a name of your choice:

# Standard environment (CPU-only):
mamba env create -f environment.yml -n isambard3-workshop -y
mamba activate isambard3-workshop

# HPC environment (Cray MPICH / MPI support --- required for Section 5 MPI examples):
mamba env create -f environment_hpc.yml -n isambard3-workshop-hpc -y
mamba activate isambard3-workshop-hpc

On Isambard 3, the dotfiles install ~/.config/pixi/config.toml with detached-environments = true. Without this, pixi stores each project’s env in .pixi/ inside the project directory. Because x86_64 and aarch64 nodes share the same home (and the same checkout), the two architectures would write incompatible binaries into the same .pixi/ folder. Detached mode stores envs in an arch-specific prefix (~/.local/opt/<arch>/) instead.

This workshop repo uses pixi + direnv internally. You do not need to understand it for today’s exercises.

Spack — for compiled software with fine-grained control over flags and dependencies:

https://docs.isambard.ac.uk/user-documentation/guides/spack/

Containers (Podman-HPC / Singularity) — for fully self-contained, portable stacks; can wrap any package manager inside:

https://docs.isambard.ac.uk/user-documentation/guides/containers/

Intro tour (official tutorials) — more worked examples on the BriCS docs site:

https://docs.isambard.ac.uk/user-documentation/tutorials/intro-tour/

If your own software stack does not fit conda, do not spend workshop time on it. Ask a helper to note it down and we will follow up after the session.