Skip to content

Submitting Jobs

about 14 minutesStudents, Staffchecked 24 August 2026

This page covers submitting Slurm batch jobs on UBELIX. If you are not already familiar with Slurm, you should read the Slurm quickstart guide which covers the basics. You can also refer to the Slurm documentation or manual pages, in particular the page about sbatch.

Every job submission starts with a resources allocation (nodes, cores, memory). An allocation is requested for a specific amount of time, and can be created using the salloc, sbatch commands. Whereas salloc and sbatch only create resource allocations, srun launches parallel tasks within such a resource allocation.

It is crucial to specify a more or less accurate runtime for your job. Requesting too little will result in job timeout, while requesting too much will have a negative impact on job start time and job throughput: Jobs with a shorter runtime have a greater chance to benefit from being backfilled and may therefore start earlier.

It is crucial to request the correct amount of memory for your job. Requesting too little memory will result in job abortion. Requesting too much memory is a waste of resources that could otherwise be allocated to other jobs.

It is crucial to request the correct amount of cores and tasks for your job. Requesting the correct amount of cores and tasks for your job is necessary for optimal job performance. To efficiently to this you need to understand the characteristics of your application:

  • Is it a serial application that can only use one core?
    Use --ntasks=1 / --cpus-per-task=1.
  • Is is able to run on a single machine using multiple cores?
    Use --ntasks=1 / --cpus-per-task=X.
  • Or does it support execution on multiple machines with MPI?
    Use --ntasks=X / --cpus-per-task=1.

The following Slurm options are required for any job:

gratis account

Option
Description
--accountSlurm account to be used by this job, i.e. gratis

paygo account

Option
Description
--accountSlurm account to be used by this job, i.e. paygo
--wckeyA valid project identifier (“wckey”) is required to use the paygo account

invest account

Option
Description
--accountSlurm account to be used by this job, i.e. invest
--qosAn investor qos needs to be supplied to run jobs in the invest account

teaching account

Option
Description
--accountSlurm account to be used by this job, i.e. teaching
--reservationA valid reservation is required to use the teaching account

Here is an overview of some of the most commonly used Slurm options.

Option
Description
--timeSet a limit on the total run time of the job allocation. Format: dd-hh:mm:ss
--partitionRequest a specific partition for the resource allocation
--qosSpecify “Quality of Service”. This can be used to change job limits, e.g. for long jobs or short jobs with large resources. See Partition/QoS page
--job-nameSpecify a job name. Example: --job-name="Simple Matlab"
--outputRedirect standard output. All directories specified in the path must exist before the job starts! By default stderr and stdout are merged into a file slurm-%j.out, where %j is the job allocation number. Example: --output=myCal_%j.out
--errorRedirect standard error. All directories specified in the path must exist before the job starts! By default stderr and stdout are merged into a file slurm-%j.out, where %j is the job allocation number. Example: --output=myCal_%j.err
--mail-userMail address to contact job owner. Must be a valid unibe email address, if used! Example:--mail-user=foo.bar@unibe.ch
--mail-typeWhen to notify a job owner: none, all, begin, end, fail, requeue, array_tasks. Example: --mail-type=end,fail
OptionDescription
--cpus-per-taskSet the number of cores per task
OptionDescription
--memSet the memory per node. Note: Try to use --mem-per-cpu or --mem-per-gpu instead.
--mem-per-cpuSet the memory per allocated CPU cores. Example: --mem-per-cpu=2G
--mem-per-gpuSet the memory per allocated GPU. Example: --mem-per-gpu=2G
OptionDescription
--gpusSet the total number of GPUs to be allocated for the job
--gpus-per-nodeSet the number of GPUs per node
--gpus-per-taskSet the number of GPUs per task

For details on how to request GPU resources on UBELIX, please see the GPUs page.

OptionDescription
--nodesNumber of nodes to be allocated to the job
--ntasksSet the maximum number of tasks (MPI ranks)
--ntasks-per-nodeSet the number of tasks per node
--ntasks-per-socketSet the number of tasks on each node
--ntasks-per-coreSet the maximum number of task on each core

The sbatch command is used to submit a job script for later execution. It is the most common way to submit a job to the cluster due to its reusability. Slurm options are usually embedded in a job script prefixed by #SBATCH directives. Slurm options specified as command line options overwrite corresponding options embedded in the job script

Syntax

bash
sbatch [options] script [args...]

A batch script is summarized by the following steps:

  • the interpreter to use for the execution of the script: bash
  • directives that define the job options: resources, run time, …
  • setting up the environment: prepare input, environment variables, …
  • run the application

The job script acts as a wrapper for your actual job. The first line is generally #!/bin/bash and specifies that the script should be interpreted as a bash script.

The lines starting with #SBATCH are directives for the workload manager. These have the general syntax

bash
#SBATCH option_name=argument

The available options are shown above and are the same as the one you use on the command line: sbatch --time=01:00:00 in the command line and #SBATCH --time=01:00:00 in a batch script are equivalent. The command line value takes precedence if the same option is present both on the command line and as a directive in a script.

The salloc command is used to allocate resources (e.g. nodes), possibly with a set of constraints (e.g. number of processor per node) for later utilization. It is typically used to allocate resources and spawn a shell, in which the srun command is used to launch parallel tasks.

Syntax

bash
salloc [options] [<command> [args...]]

Example

bash
bash$ salloc -N 2 -t 10
salloc: Granted job allocation 247
bash$ module load foss
bash$ srun ./mpi_hello_world
Hello, World. I am 1 of 2 running on cnode03.hpc.unibe.ch
Hello, World. I am 0 of 2 running on cnode02.hpc.unibe.ch
bash$ exit
salloc: Relinquishing job allocation 247

The srun command creates job steps. One or multiple srun invocations are usually used from within an existing resource allocation. Thereby, a job step can utilize all resources allocated to the job, or utilize only a subset of the resource allocation. Multiple job steps can run sequentially in the order defined in the batch script or run in parallel, but can together never utilize more resources than provided by the allocation.

Syntax

batch
srun [options] executable [args...]

Use srun in your job script for executables if these are:

  • MPI applications
  • multiple job tasks (serial or parallel jobs) simultaneously within an allocation

Example Run MPI task:

bash
#!/bin/bash
#SBATCH --job-name="Open MPI example"
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=20
#SBATCH --mem-per-cpu=2G
#SBATCH --time=06:00:00
# Your code below this line
module load foss
srun ./mpi_app.exe

Run two jobs simultaneously:

bash
#!/bin/bash
#SBATCH --job-name="Simultaneous example"
#SBATCH --ntasks=2
#SBATCH --cpus-per-task=4
# Your code below this line
# run 2 threaded applications side-by-side
srun --tasks=1 --cpus-per-task=4 ./app1 inp1.dat &
srun --tasks=1 --cpus-per-task=4 ./app2 inp2.dat &
wait
# wait: Wait for both background commands to finish. This is important when running bash commands in the background (using &)! Otherwise, the job ends immediately.

Please run series of similar tasks as job array. See Array Jobs.

Per default jobs are submitted to the epyc2 partition and the default QoS job_cpu. The partition option can be used to request different hardware, e.g. gpu partition. And the QoS can be used to run in a specific queue, e.g. job_gpu_debug:

bash
#SBATCH --partition=gpu
#SBATCH --qos=job_gpu_debug

See Partitions / QoS for a list of available partitions and QoS and its specifications.

Running a serial job with email notification in case of error (1 task is default value):

gratis account

bash
#!/bin/bash
#------------------------
#SBATCH --account=gratis
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="Serial Job"
#SBATCH --time=00:10:00
# Your code below this line
echo "I'm on host: $HOSTNAME"

paygo account

bash
#!/bin/bash
#------------------------
#SBATCH --account=paygo
#SBATCH --wckey=<wckey>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="Serial Job"
#SBATCH --time=00:10:00
# Your code below this line
echo "I'm on host: $HOSTNAME"

invest account

bash
#!/bin/bash
#------------------------
#SBATCH --account=invest
#SBATCH --qos=<investor_qos>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="Serial Job"
#SBATCH --time=00:10:00
# Your code below this line
echo "I'm on host: $HOSTNAME"

teaching account

bash
#!/bin/bash
#------------------------
#SBATCH --account=teaching
#SBATCH --reservation=<reservation>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="Serial Job"
#SBATCH --time=00:10:00
# Your code below this line
echo "I'm on host: $HOSTNAME"

Shared Memory Jobs (e.g. OpenMP)

SMP parallelization is based upon dynamically created threads (fork and join) that share memory on a single node. The key request is --cpus-per-task. To run N threads in parallel, we request N CPUs on the node (--cpus-per-task=N).

gratis account

bash
#!/bin/bash
#------------------------
#SBATCH --account=gratis
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="SMP Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --cpus-per-task=16
#SBATCH --time=01:00:00
# Your code below this line
srun ./my_binary

paygo account

bash
#!/bin/bash
#------------------------
#SBATCH --account=paygo
#SBATCH --wckey=<wckey>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="SMP Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --cpus-per-task=16
#SBATCH --time=01:00:00
# Your code below this line
srun ./my_binary

invest account

bash
#!/bin/bash
#------------------------
#SBATCH --account=invest
#SBATCH --qos=<investor_qos>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="SMP Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --cpus-per-task=16
#SBATCH --time=01:00:00
# Your code below this line
srun ./my_binary

teaching account

bash
#!/bin/bash
#------------------------
#SBATCH --account=teaching
#SBATCH --reservation=<reservation>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="SMP Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --cpus-per-task=16
#SBATCH --time=01:00:00
# Your code below this line
srun ./my_binary

MPI Jobs (e.g. Open MPI)

MPI parallelization is based upon processes (local or distributed) that communicate by passing messages. Since they don’t rely on shared memory those processes can be distributed among several compute nodes. Use the option --ntasks to request a certain number of tasks (processes) that can be distributed over multiple nodes:

gratis account

bash
#!/bin/bash
#------------------------
#SBATCH --account=gratis
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --ntasks=8
#SBATCH --time=04:00:00
# Your code below this line
# First set the environment for using Open MPI
module load foss
srun ./my_binary

paygo account

bash
#!/bin/bash
#------------------------
#SBATCH --account=paygo
#SBATCH --wckey=<wckey>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --ntasks=8
#SBATCH --time=04:00:00
# Your code below this line
# First set the environment for using Open MPI
module load foss
srun ./my_binary

invest account

bash
#!/bin/bash
#------------------------
#SBATCH --account=invest
#SBATCH --qos=<investor_qos>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --ntasks=8
#SBATCH --time=04:00:00
# Your code below this line
# First set the environment for using Open MPI
module load foss
srun ./my_binary

teaching account

bash
#!/bin/bash
#------------------------
#SBATCH --account=teaching
#SBATCH --reservation=<reservation>
#------------------------
#SBATCH --mail-user=foo.bar@unibe.ch
#SBATCH --mail-type=end
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --ntasks=8
#SBATCH --time=04:00:00
# Your code below this line
# First set the environment for using Open MPI
module load foss
srun ./my_binary

On the partition you must use all CPUs provided by a node (20 CPUs). For example to run an OMPI job on 80 CPUs, do:

gratis account

bash
#!/bin/bash
#------------------------
#SBATCH --account=gratis
#------------------------
#SBATCH --mail-user=foo.bar@baz.unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --nodes=4 ## or --ntasks=80
#SBATCH --ntasks-per-node=20
#SBATCH --time=12:00:00
# Your code below this line
module load foss
srun ./my_binary

paygo account

bash
#!/bin/bash
#------------------------
#SBATCH --account=paygo
#SBATCH --wckey=<wckey>
#------------------------
#SBATCH --mail-user=foo.bar@baz.unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --nodes=4 ## or --ntasks=80
#SBATCH --ntasks-per-node=20
#SBATCH --time=12:00:00
# Your code below this line
module load foss
srun ./my_binary

invest account

bash
#!/bin/bash
#------------------------
#SBATCH --account=invest
#SBATCH --qos=<investor_qos>
#------------------------
#SBATCH --mail-user=foo.bar@baz.unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --nodes=4 ## or --ntasks=80
#SBATCH --ntasks-per-node=20
#SBATCH --time=12:00:00
# Your code below this line
module load foss
srun ./my_binary

teaching account

bash
#!/bin/bash
#------------------------
#SBATCH --account=teaching
#SBATCH --reservation=<reservation>
#------------------------
#SBATCH --mail-user=foo.bar@baz.unibe.ch
#SBATCH --mail-type=end,fail
#SBATCH --job-name="MPI Job"
#SBATCH --mem-per-cpu=2G
#SBATCH --nodes=4 ## or --ntasks=80
#SBATCH --ntasks-per-node=20
#SBATCH --time=12:00:00
# Your code below this line
module load foss
srun ./my_binary

For information on how to run GPU jobs on UBELIX, please see the GPUs page.

The UBELIX Slurm configuration has automatic requeuing of jobs upon node failure enabled. It means that if a node fails, your job will be automatically resubmitted to the queue and will have the same job ID and possibly truncate the previous output. Here are some important parameters you can use to alter the default behavior.

  • you can disable automatic requeuing using the --no-requeue option
  • you can avoid your output file being truncated in case of requeuing by using the --open-mode=append option

If you want to perform specific operations in your batch script when a job has been requeued, you can check the value of the SLURM_RESTART_COUNT variable. The value of this variable will be 0 if it is the first time the job is run. If the job has been restarted, the value will be the number of times the job has been restarted.

Below are some common error messages you may get when your job submission fails.

The complete error message is:

sbatch: error: AssocMaxSubmitJobLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)

The most common causes are:

  • your project has already used all of its allocated compute resources.
  • job script is missing the --account parameter.
  • your project has exceeded the limit for the number of simultaneous jobs, either running or queuing. Note that Slurm counts each job within an array job as a separate job.

Slurm sets various environment variables available in the context of the job script. Some are set based on the requested resources for the job.

Environment VariableSet By OptionDescription
SLURM_JOB_NAME--job-nameName of the job
SLURM_ARRAY_JOB_IDID of your job
SLURM_ARRAY_TASK_ID--arrayID of the current array task
SLURM_ARRAY_TASK_MAX--arrayJob array’s maximum ID (index) number
SLURM_ARRAY_TASK_MIN--arrayJob array’s minimum ID (index) number
SLURM_ARRAY_TASK_STEP--arrayJob array’s index step size
SLURM_NTASKS--ntasksSame as -n, --ntasks
SLURM_NTASKS_PER_NODE--ntasks-per-nodeNumber of tasks requested per node. Only set if the --ntasks-per-node option is specified
SLURM_CPUS_PER_TASK--cpus-per-taskNumber of cpus requested per task. Only set if the --cpus-per-task option is specified
TMPDIRReferences the disk space for the job on the local scratch

For the full list, see man sbatch