Haars0011: Phase 1 § 4 P1.4.4: merge Creating sbatch script + Using Slurm § Submitting into Batch Jobs (via create-page on MediaWiki MCP Server)

2026-06-16T09:28:22Z

Phase 1 § 4 P1.4.4: merge Creating sbatch script + Using Slurm § Submitting into Batch Jobs (via create-page on MediaWiki MCP Server)

New page

A batch job is the standard way to run unattended work on Anunna. You write a shell script that declares the resources you need (CPUs, memory, wall time) and the commands you want to run, then hand the script to <code>sbatch</code>. SLURM queues the job, runs it on a compute node when resources are free, and writes the output to a file you specified.

This page covers the mechanics: how a batch script is laid out, what each <code>#SBATCH</code> directive does, and how to submit one or many jobs at once. For node selection (partition, GPU, hardware constraints) see [[Choosing a node (constraints)]]; for tracking submitted jobs see [[Monitoring job execution | Monitoring jobs]].

== A worked example ==

Suppose you have a Python script <code>calc_pi.py</code> that calculates π to one million digits:

<syntaxhighlight lang="python">
from decimal import *
D = Decimal
getcontext().prec = 10000000
p = sum(D(1)/16**k * (D(4)/(8*k+1) - D(2)/(8*k+4) - D(1)/(8*k+5) - D(1)/(8*k+6)) for k in range(411))
print(str(p)[:10000002])
</syntaxhighlight>

To run it on the cluster you need to (1) load the right Python module and (2) wrap the script in a batch submission file.

=== Loading modules ===

Check which Python versions are available:

<syntaxhighlight lang="bash">
module avail Python
</syntaxhighlight>

Pick one and load it from the appropriate year bucket — see [[Modules]] for the bucket-and-version convention.

=== Batch script ===

Save the following as <code>run_calc_pi.sh</code>:

<syntaxhighlight lang="bash">
#!/bin/bash
#SBATCH --comment=773320000
#SBATCH --time=1200
#SBATCH --mem=2048
#SBATCH --cpus-per-task=1
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
#SBATCH --job-name=calc_pi.py
#SBATCH --mail-type=ALL
#SBATCH --mail-user=email@org.nl

module load 2023
module load Python/3.11.3

time python3 calc_pi.py
</syntaxhighlight>

=== Submitting ===

Submit the job:

<syntaxhighlight lang="bash">
sbatch run_calc_pi.sh
</syntaxhighlight>

SLURM responds with a job ID. Track progress with [[Monitoring job execution | <code>squeue</code> and <code>sacct</code>]], or cancel with [[Cancelling Jobs | <code>scancel</code>]].

== Skeleton script ==

A reasonable starting template:

<syntaxhighlight lang="bash">
#!/bin/bash

#-----------------------------Mail address-----------------------------
#SBATCH --mail-user=
#SBATCH --mail-type=ALL
#-----------------------------Output files-----------------------------
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
#-----------------------------Other information------------------------
#SBATCH --comment=
#SBATCH --qos=
#-----------------------------Required resources-----------------------
#SBATCH --time=0-0:0:0
#SBATCH --ntasks=
#SBATCH --cpus-per-task=
#SBATCH --mem-per-cpu=

#-----------------------------Environment, Operations and Job steps----
# load modules

# export variables

# your job
</syntaxhighlight>

== Common #SBATCH directives ==

For partition, hardware constraints, and GPU requests see [[Choosing a node (constraints)]]. The directives below are the ones you use to size the job and control its bookkeeping.

=== Time limit ===

<syntaxhighlight lang="bash">
#SBATCH --time=1200
</syntaxhighlight>

Acceptable time formats: <code>minutes</code>, <code>minutes:seconds</code>, <code>hours:minutes:seconds</code>, <code>days-hours</code>, <code>days-hours:minutes</code>, <code>days-hours:minutes:seconds</code>. A time limit of zero disables the limit. The example above caps the job at 1200 minutes.

=== Memory ===

<syntaxhighlight lang="bash">
#SBATCH --mem=2048
</syntaxhighlight>

SLURM enforces a memory limit per job. The default is deliberately small — 100 MB per node — so most real work needs an explicit value. The argument is in MB (or use a suffix: <code>K</code>, <code>M</code>, <code>G</code>, <code>T</code>).

Pick a value slightly larger than what your job actually needs. Too low and the job is killed; too high and it is harder for SLURM to find a place to run it. A starting heuristic is 4000 MB per core; tune from there. To see what a finished job actually used:

<syntaxhighlight lang="bash">
sacct -o MaxRSS -j <jobid>
</syntaxhighlight>

The value is in KB; divide by 1024 to get MB. If the job finished a while ago, broaden the search with <code>-S YYYY-MM-DD</code>.

For multi-node jobs the value is the maximum used on any one node; uneven task distribution can make this fluctuate between runs.

=== Number of tasks and CPUs ===

<syntaxhighlight lang="bash">
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
</syntaxhighlight>

<code>sbatch</code> does not launch tasks itself — it reserves resources and runs the batch script. <code>--ntasks</code> tells SLURM the upper bound on job steps that may run inside the allocation; <code>--cpus-per-task</code> reserves that many CPUs for each task. The default is one task per node, but setting <code>--cpus-per-task</code> changes the default task count.

To pin the job to a single node:

<syntaxhighlight lang="bash">
#SBATCH --nodes=1
</syntaxhighlight>

If only one number is given for <code>--nodes</code>, SLURM treats it as both minimum and maximum.

=== Local disk on the compute node ===

<syntaxhighlight lang="bash">
#SBATCH --tmp=<required size>
</syntaxhighlight>

Each compute node has a local disk of around 300 GB at <code>/tmp</code> that you can use for staging. The disk is shared with other jobs on the node, so request the amount you need so SLURM places your job on a node where it is actually available. Clean up after yourself when the job ends.

=== Output and error files ===

<syntaxhighlight lang="bash">
#SBATCH --output=output_%j.txt
#SBATCH --error=error_output_%j.txt
</syntaxhighlight>

Redirect the batch script's standard output and standard error to files. The default for both is <code>slurm-%j.out</code>. The pattern <code>%j</code> is replaced with the job ID.

=== Job name ===

<syntaxhighlight lang="bash">
#SBATCH --job-name=calc_pi.py
</syntaxhighlight>

A short label that appears next to the job ID in <code>squeue</code>. Defaults to the script name, or <code>sbatch</code> if the script came from standard input.

=== Email notifications ===

<syntaxhighlight lang="bash">
#SBATCH --mail-type=ALL
#SBATCH --mail-user=yourname001@wur.nl
</syntaxhighlight>

Valid <code>--mail-type</code> values are <code>BEGIN</code>, <code>END</code>, <code>FAIL</code>, <code>REQUEUE</code>, and <code>ALL</code>. Combine with <code>--mail-user</code> to choose the recipient.

=== Comment / project accounting ===

<syntaxhighlight lang="bash">
#SBATCH --comment=773320000
</syntaxhighlight>

The comment is an arbitrary string that ends up in accounting records. For WUR users this is the place to put a project number or KTP number. The comment can be changed after submission with <code>scontrol</code>.

== Submitting many jobs at once ==

=== Simple loop ===

To submit ten independent scripts <code>runscript_1.sh</code> through <code>runscript_10.sh</code>:

<syntaxhighlight lang="bash">
for i in $(seq 1 10); do
echo "$i"
sbatch "runscript_${i}.sh"
done
</syntaxhighlight>

=== Job dependencies ===

To make one job wait for another to finish, capture the job ID returned by <code>sbatch</code> and pass it to the next submission via <code>--dependency</code>:

<syntaxhighlight lang="bash">
#!/bin/bash
JOB1=$(sbatch --parsable job_1.sh)
echo "Submitted $JOB1"

JOB2=$(sbatch --parsable --dependency=afterany:$JOB1 job_2.sh)
echo "Submitted $JOB2 (waits for $JOB1)"

JOB3=$(sbatch --parsable --dependency=afterany:$JOB2 job_3.sh)
echo "Submitted $JOB3 (waits for $JOB2)"
</syntaxhighlight>

The <code>--parsable</code> flag makes <code>sbatch</code> print just the job ID, which is convenient for capturing into a shell variable. <code>afterany</code> triggers the next job whether the previous one succeeded or failed; <code>afterok</code> only triggers on success. For array job dependencies, <code>aftercorr</code> matches array elements one-to-one.

See [https://slurm.schedmd.com/sbatch.html#OPT_dependency the sbatch documentation] for the full list of dependency types.

== Array jobs ==

If you need to run the same script many times with a varying parameter, an array job is far more efficient than a submission loop. Add:

<syntaxhighlight lang="bash">
#SBATCH --array=0-10%4
</syntaxhighlight>

This submits 11 jobs (indices 0–10) with at most 4 running at once. See [[Array jobs]] for details.

== See also ==

* [[Partitions / Queues]]
* [[Choosing a node (constraints)]]
* [[Interactive Jobs]]
* [[Array jobs]]
* [[Cancelling Jobs]]
* [[Monitoring job execution | Monitoring jobs]]
* [[Using Slurm | Scheduler overview]]
* [https://slurm.schedmd.com/sbatch.html sbatch documentation]

Batch Jobs - Revision history

Haars0011: Phase 1 § 4 P1.4.4: merge Creating sbatch script + Using Slurm § Submitting into Batch Jobs (via create-page on MediaWiki MCP Server)