Skip to main content
Back to module
Computational & Modern Physics · Physics Data

HPC and research software

Reading32mLesson 3 of 3 in this module

What you'll learn

  • Explain clusters and reproducible code
  • Write and submit a Slurm batch job
  • Estimate the speed-up limit with Amdahl's law
  • Apply version control, pinned environments, seeds and tests to research code

Explain how clusters, schedulers and parallel code work, and the habits that make research software reproducible.

Why it matters

Modern physics runs on software. Lattice QCD, climate models, galaxy simulations, gravitational-wave searches and detector reconstruction all need more computing than a laptop, and their results are only as trustworthy as the code. Knowing how high-performance computing (HPC) works and how to write reproducible research software is now a core physicist skill, and research software engineering is a career in its own right.

What a cluster is

An HPC cluster is many computers (nodes) connected by a fast network.

  • Login nodes: where you connect with ssh, edit files and submit jobs. Never run heavy work here.
  • Compute nodes: each has many CPU cores (often 32 to 128), lots of memory, and sometimes GPUs.
  • Interconnect: a low-latency network (such as InfiniBand) so nodes can exchange data quickly.
  • Shared parallel file system: large, fast storage visible from every node, usually with a scratch area that is purged regularly and is not backed up.

Schedulers and jobs

You don't run programs directly on compute nodes; you ask a scheduler (Slurm is the most common) for resources, and it queues your job until they are free.

#!/bin/bash
#SBATCH --job-name=heat-scan
#SBATCH --nodes=1
#SBATCH --ntasks=32
#SBATCH --time=02:00:00
#SBATCH --mem=64G

module load python/3.12
srun python run_scan.py --config scan.yaml

You submit with sbatch job.sh, check the queue with squeue, and cancel with scancel. Asking for realistic time and memory gets your job started sooner. Computing time is a shared, allocated resource, often granted through proposals.

Kinds of parallelism

  • Embarrassingly parallel: many independent runs (parameter scans, Monte Carlo seeds). The easiest and most common; use job arrays.
  • Shared memory (OpenMP, threads): many cores on one node working on the same arrays.
  • Distributed memory (MPI): processes on many nodes, each owning part of the problem (for example, part of a grid) and exchanging boundary data with messages.
  • GPUs (CUDA, HIP, or Python tools such as CuPy and JAX): thousands of simple cores, ideal for dense array maths.

Amdahl's law

If a fraction p of the work can run in parallel on N cores, the speed-up is limited:

S = 1 / ((1 - p) + p / N)
p = 0.9, N = 8:    S = 1 / (0.1 + 0.1125) = 4.7
p = 0.9, N = 1000: S = 1 / (0.1 + 0.0009) = 9.9   (never more than 10)

The serial part dominates quickly. Strong scaling asks how fast a fixed problem gets with more cores; weak scaling asks whether a problem that grows with the core count keeps the same run time. Measure both before asking for a large allocation.

Reproducible research software

A result is reproducible if someone else (or you, in a year) can regenerate it from the same data and code.

  • Version control: every analysis lives in git; record the commit hash with every result.
  • Pinned environments: a requirements.txt with versions, a conda environment.yml, or a container (Apptainer, Docker).
  • Seeds and configuration: random seeds and parameters live in config files, not in your head.
  • Tests: check the code against known answers (exact solutions, conservation laws), like the checks in this course.
  • Data provenance: keep raw data read-only and record each processing step.
  • Sharing and credit: publish code with a licence, archive a release with a DOI (Zenodo is free), add a CITATION.cff file, and follow the FAIR principles (findable, accessible, interoperable, reusable).

Careers and requirements

National labs, universities and companies employ physicists and research software engineers (RSEs) for this work. Physicist roles need at least a bachelor's degree in physics, and most research positions require a PhD. Many universities offer free HPC training; the Carpentries (https://carpentries.org) teach the core software habits. Checked on 2026-10-23.

Recap

  • Clusters have login and compute nodes, a fast network and shared storage; a scheduler such as Slurm runs your jobs.
  • Parallelism ranges from independent runs to MPI and GPUs; Amdahl's law caps the speed-up.
  • Version control, pinned environments, seeds, tests and DOIs make research code reproducible.

Key terms (6)

Login nodes
The cluster machines you connect to with ssh to edit files and submit jobs; heavy work never runs there.
scheduler
Software such as Slurm that queues jobs and runs them on compute nodes when the requested resources are free.
Embarrassingly parallel
Work made of many independent runs, such as parameter scans or Monte Carlo seeds, that need no communication.
Amdahl's law
S = 1 / ((1 - p) + p / N): the serial fraction of the work caps the speed-up from N cores.
Strong scaling
How much faster a fixed-size problem runs as the number of cores grows.
reproducible
Describes a result that someone else, or you later, can regenerate from the same data and code.

Recap

  • A cluster has login and compute nodes, a fast interconnect and shared storage.
  • A scheduler such as Slurm runs jobs you submit with sbatch; ask for realistic time and memory.
  • Parallelism ranges from independent runs to OpenMP, MPI and GPUs.
  • Amdahl's law caps the speed-up by the serial fraction.
  • Version control, pinned environments, seeds, tests and archived releases make research code reproducible.
Also in this lesson: