A live subject
Last updated on 2026-10-26 | Edit this page
This page runs one small program through the whole day, so the
episodes share a subject. The program is
episodes/files/pi_one.py. It estimates pi with a fixed
sequence of points. SAMPLE_COUNT sets how many points. The
same count always prints the same estimate.
The four sample sizes are listed in
learners/sample-buildlist:
1000
2000
4000
8000Morning: one size, on the login node or in the container
1000 points is small enough to run in front of you.
You should see one line that starts with samples=1000.
If python3 is the system Python, load the EESSI module from
the software episode first. The estimate does not depend on which Python
you use. The path printed by which python3 does.
Late morning: the same size, through Slurm
On the course cluster, submit
episodes/files/pi-course.sh from a directory that contains
pi_one.py. On Snellius, submit
episodes/files/pi-snellius.sh. Read
pi-<jobid>.out when the job leaves the queue. The
line in that file matches the line you already saw.
Afternoon: four sample sizes, one array
episodes/files/pi-array.sh maps task 0, 1, 2, and 3 onto
the four sample sizes. Task 2 uses 4000. Each task writes
pi-<arrayid>_<task>.out.
You now have four text files. They are small. If you were moving a
directory of outputs off the cluster, you would tar them
first and check the archive with sha256sum -c, as in the
files episode. Four tiny files are not that problem. A parameter study
with thousands of outputs is.
If the tasks are too short for one job each
The array is the right tool while Slurm is tracking a handful of
tasks. When the count grows into the thousands, the many-tasks episode
is the next step: one allocation, and QCG-PilotJob inside it. The
three-task script in that episode is the same idea as this array, with a
manager instead of --array.
Last hour: did the cores help
episodes/files/timings.csv is a strong-scaling series
for a fixed amount of work, not for these four sample sizes. A larger
SAMPLE_COUNT takes longer because it is more work. That is
not a slower program. Compare time -p only when the count
and the code stay the same.
Write down the estimate from task 0 and the efficiency from the timing table before you leave. Those two numbers are the whole day in one line each.