DSV Slurm documentation - User contributions [en-gb]

Hardware specifications for Olympus

2026-06-02T11:52:04Z

Erth9960(AT)su.se:

These are the partitions available for use on Olympus, with their respective hardware specifications. Partition names are case sensitive, so they are reproduced here in the format that is valid in a slurm job specification.

== cpu ==
The default partition if a job doesn't specify a partition to use. Mostly intended for testing, since the nodes are fairly weak in comparison to other partitions.

== cpu_large ==
This partition contains nodes which provide a lot of CPU cores and RAM, but no GPUs.

== gpu ==
This is the main GPU partition, where GPU jobs should be pointed unless there is some specific reason not to.

Main Page

2026-06-02T11:51:00Z

Erth9960(AT)su.se:

This is the documentation site for working with Slurm at DSV. The site is a work in progress and will grow over time as usage patterns become clear.

DSV currently has a single small Slurm cluster called Olympus. It is available to staff and thesis students by individual request as detailed [[Applying for access|here]].

Some useful starting points:

* [[Applying for access]]
* [[Getting started]]
* [[Hardware specifications for Olympus]] (this page also lists the available partitions)

If you are wondering about the names, slurm is a soft drink from the TV show Futurama, and it's produced on the planet Wormulon. Hosting the documentation on the planet of origin seemed appropriate.

Main Page

2026-06-02T11:49:25Z

Erth9960(AT)su.se:

This is the documentation site for working with Slurm at DSV. The site is a work in progress and will grow over time as usage patterns become clear.

DSV currently has a single small Slurm cluster called Olympus. It is available to staff and thesis students by individual request as detailed [[Applying for access|here]].

Some useful starting points:

* [[Applying for access]]
* [[Getting started]]
* [[Hardware specifications for Olympus]]

If you are wondering about the names, slurm is a soft drink from the TV show Futurama, and it's produced on the planet Wormulon. Hosting the documentation on the planet of origin seemed appropriate.

Getting started

2026-05-21T13:11:25Z

Erth9960(AT)su.se: /* Submitting your job */

This document should help you get started with logging in to the cluster and running a "Hello world" script as a slurm job.

== Accessing the cluster ==
First you need to apply for access to the cluster if you haven't already, see [[Applying for access|this page]] for details. Once you have been granted access, you will need to configure a VPN connection in order to be able to communicate with the server. Students can set up a VPN connection at https://vpn-student.dsv.su.se.

When your VPN connection is up and running, you connect to the cluster using an SSH client and your SU credentials. The server address is <code>olympus.dsv.su.se</code>.

<syntaxhighlight>
me@mylaptop:~$ ssh erth9960@olympus.dsv.su.se
erth9960@olympus's password:
Linux slurm-login 6.1.0-44-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.164-1 (2026-03-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Apr 15 14:01:10 2026 from vpn-student-wgi.dsv.su.se
erth9960@slurm-login:~$

</syntaxhighlight>

When you have successfully logged in, you can move on to running your first Slurm job.

== Running code as a slurm job ==
Running code on slurm is always an asynchronous process. In other words you submit a job to the queue, Slurm schedules the job for execution when relevant resources are available, and any output from your job is recorded in a file.

=== Preparing your script ===

Write the following code into a file named <code>hello-slurm.sh</code>

<syntaxhighlight lang="bash">#!/bin/bash
#SBATCH --job-name=testjob
#SBATCH --partition=cpu

echo "Hello $HOSTNAME"</syntaxhighlight>

The initial <code>#SBATCH</code> comments are special commands read by Slurm, passing instructions about how to execute your job. Here we only choose a name for the job and which partition to run it on. An incomplete list of useful sbatch arguments is available [[Useful sbatch arguments|here]].

<code>$HOSTNAME</code> is an environment variable that contains the name of the server the code is running on.

=== Submitting your job ===
Once you have saved your script, you queue it for execution by running the following command:

<syntaxhighlight>
sbatch hello-slurm.sh
</syntaxhighlight>

You should see output similar to this:

<syntaxhighlight>
Submitted batch job 1928
</syntaxhighlight>

Since the script does very little work it will probably execute immediately, but if it doesn't you can see its place in the queue by running the command <code>squeue</code>. You can also see details about your job by running <code>scontrol show job NN</code>, where NN is the job ID that was printed (1928 in this example).

=== Reading job output ===
Since the job is run asynchronously, the output from your job will not be printed to your terminal as usual but written to a file. We don't specify a filename to use, so slurm will use the default name. The default name is <code>slurm-NN.out</code>, where NN is the job ID.

You can read the resulting file with any tool that can read text files, such as <code>cat</code>:

<syntaxhighlight lang="bash">
erth9960@slurm-login:~$ cat slurm-1928.out
Hello slurm-node-cpu-01
</syntaxhighlight>

Here you can see that the code executed on <code>slurm-node-cpu-01</code>, as opposed to <code>slurm-login</code> which is where your terminal session is running.

== Further reading ==
A more ambitious example job, which deals with a slightly more complex Python scenario is available at https://gitea.dsv.su.se/erth9960/slurm-gpu-test.

Getting started

2026-05-21T13:11:07Z

Erth9960(AT)su.se:

This document should help you get started with logging in to the cluster and running a "Hello world" script as a slurm job.

== Accessing the cluster ==
First you need to apply for access to the cluster if you haven't already, see [[Applying for access|this page]] for details. Once you have been granted access, you will need to configure a VPN connection in order to be able to communicate with the server. Students can set up a VPN connection at https://vpn-student.dsv.su.se.

When your VPN connection is up and running, you connect to the cluster using an SSH client and your SU credentials. The server address is <code>olympus.dsv.su.se</code>.

<syntaxhighlight>
me@mylaptop:~$ ssh erth9960@olympus.dsv.su.se
erth9960@olympus's password:
Linux slurm-login 6.1.0-44-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.164-1 (2026-03-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Apr 15 14:01:10 2026 from vpn-student-wgi.dsv.su.se
erth9960@slurm-login:~$

</syntaxhighlight>

When you have successfully logged in, you can move on to running your first Slurm job.

== Running code as a slurm job ==
Running code on slurm is always an asynchronous process. In other words you submit a job to the queue, Slurm schedules the job for execution when relevant resources are available, and any output from your job is recorded in a file.

=== Preparing your script ===

Write the following code into a file named <code>hello-slurm.sh</code>

<syntaxhighlight lang="bash">#!/bin/bash
#SBATCH --job-name=testjob
#SBATCH --partition=cpu

echo "Hello $HOSTNAME"</syntaxhighlight>

The initial <code>#SBATCH</code> comments are special commands read by Slurm, passing instructions about how to execute your job. Here we only choose a name for the job and which partition to run it on. An incomplete list of useful sbatch arguments is available [[Useful sbatch arguments|here]].

<code>$HOSTNAME</code> is an environment variable that contains the name of the server the code is running on.

=== Submitting your job ===
Once you have saved your script, you queue it for execution by running the following command:

<syntaxhighlight lang="bash">
sbatch hello-slurm.sh
</syntaxhighlight>

You should see output similar to this:

<syntaxhighlight>
Submitted batch job 1928
</syntaxhighlight>

Since the script does very little work it will probably execute immediately, but if it doesn't you can see its place in the queue by running the command <code>squeue</code>. You can also see details about your job by running <code>scontrol show job NN</code>, where NN is the job ID that was printed (1928 in this example).

=== Reading job output ===
Since the job is run asynchronously, the output from your job will not be printed to your terminal as usual but written to a file. We don't specify a filename to use, so slurm will use the default name. The default name is <code>slurm-NN.out</code>, where NN is the job ID.

You can read the resulting file with any tool that can read text files, such as <code>cat</code>:

<syntaxhighlight lang="bash">
erth9960@slurm-login:~$ cat slurm-1928.out
Hello slurm-node-cpu-01
</syntaxhighlight>

Here you can see that the code executed on <code>slurm-node-cpu-01</code>, as opposed to <code>slurm-login</code> which is where your terminal session is running.

== Further reading ==
A more ambitious example job, which deals with a slightly more complex Python scenario is available at https://gitea.dsv.su.se/erth9960/slurm-gpu-test.

Hardware specifications for Olympus

2026-04-29T11:00:54Z

Erth9960(AT)su.se: Created page with "These are the partitions available for use on Olympus, with their respective hardware specifications. == CPU == The default partition if a job doesn't specify a partition to use. Mostly intended for testing, since the nodes are fairly weak in comparison to other partitions. == CPU_large == This partition contains nodes which provide a lot of CPU cores and RAM, but no GPUs. == GPU == This is the main GPU partition, where GPU jobs should be pointed unless there is some..."

These are the partitions available for use on Olympus, with their respective hardware specifications.

== CPU ==
The default partition if a job doesn't specify a partition to use. Mostly intended for testing, since the nodes are fairly weak in comparison to other partitions.

== CPU_large ==
This partition contains nodes which provide a lot of CPU cores and RAM, but no GPUs.

== GPU ==
This is the main GPU partition, where GPU jobs should be pointed unless there is some specific reason not to.

Getting started

2026-04-28T14:48:03Z

Erth9960(AT)su.se:

This document should help you get started with logging in to the cluster and running a "Hello world" script as a slurm job.

== Accessing the cluster ==
First you need to apply for access to the cluster if you haven't already, see [[Applying for access|this page]] for details. Once you have been granted access, you will need to configure a VPN connection in order to be able to communicate with the server. Students can set up a VPN connection at https://vpn-student.dsv.su.se.

When your VPN connection is up and running, you connect to the cluster using an SSH client and your SU credentials. The server address is <code>olympus.dsv.su.se</code>.<syntaxhighlight>
me@mylaptop:~$ ssh erth9960@olympus.dsv.su.se
erth9960@olympus's password:
Linux slurm-login 6.1.0-44-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.164-1 (2026-03-09) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Apr 15 14:01:10 2026 from vpn-student-wgi.dsv.su.se
erth9960@slurm-login:~$

</syntaxhighlight>When you have successfully logged in, you can move on to running your first Slurm job.

== Running code as a slurm job ==
Running code on slurm is always an asynchronous process. In other words you submit a job to the queue, Slurm schedules the job for execution when relevant resources are available, and any output from your job is recorded in a file.

=== Preparing your script ===

Write the following code into a file named <code>hello-slurm.sh</code>

<syntaxhighlight lang="bash">#!/bin/bash
#SBATCH --job-name=testjob
#SBATCH --partition=cpu

echo "Hello $HOSTNAME"</syntaxhighlight>

The initial <code>#SBATCH</code> comments are special commands read by Slurm, passing instructions about how to execute your job. Here we only choose a name for the job and which partition to run it on. An incomplete list of useful sbatch arguments is available [[Useful sbatch arguments|here]].

<code>$HOSTNAME</code> is an environment variable that contains the name of the server the code is running on.

=== Submitting your job ===
Once you have saved your script, you queue it for execution by running the following command:<syntaxhighlight lang="bash">
sbatch hello-slurm.sh
</syntaxhighlight>You should see output similar to this:<syntaxhighlight>
Submitted batch job 1928

</syntaxhighlight>Since the script does very little work it will probably execute immediately, but if it doesn't you can see its place in the queue by running the command <code>squeue</code>. You can also see details about your job by running <code>scontrol show job NN</code>, where NN is the job ID that was printed (1928 in this example).

=== Reading job output ===
Since the job is run asynchronously, the output from your job will not be printed to your terminal as usual but written to a file. We don't specify a filename to use, so slurm will use the default name. The default name is <code>slurm-NN.out</code>, where NN is the job ID.

You can read the resulting file with any tool that can read text files, such as <code>cat</code>:<syntaxhighlight lang="bash">
erth9960@slurm-login:~$ cat slurm-1928.out
Hello slurm-node-cpu-01

</syntaxhighlight>Here you can see that the code executed on <code>slurm-node-cpu-01</code>, as opposed to <code>slurm-login</code> which is where your terminal session is running.

== Further reading ==
A more ambitious example job, which deals with a slightly more complex Python scenario is available at https://gitea.dsv.su.se/erth9960/slurm-gpu-test.

Getting started

2026-04-28T14:37:13Z

Erth9960(AT)su.se: Created page with "This document should help you get started with logging in to the cluster and running a "Hello world" script as a slurm job. Running code on slurm is always an asynchronous process. In other words you submit a job to the queue, Slurm schedules the job for execution when relevant resources are available, and any output from your job is recorded in a file. === Preparing your script === Write the following code into a file named <code>hello-slurm.sh</code> <syntaxhighlig..."

This document should help you get started with logging in to the cluster and running a "Hello world" script as a slurm job.

Running code on slurm is always an asynchronous process. In other words you submit a job to the queue, Slurm schedules the job for execution when relevant resources are available, and any output from your job is recorded in a file.

=== Preparing your script ===

Write the following code into a file named <code>hello-slurm.sh</code>

<syntaxhighlight lang="bash">#!/bin/bash
#SBATCH --job-name=testjob
#SBATCH --partition=cpu

echo "Hello $HOSTNAME"</syntaxhighlight>

The initial <code>#SBATCH</code> comments are special commands read by Slurm, passing instructions about how to execute your job. Here we only choose a name for the job and which partition to run it on. An incomplete list of useful sbatch arguments is available [[Useful sbatch arguments|here]].

<code>$HOSTNAME</code> is an environment variable that contains the name of the server the code is running on.

=== Submitting your job ===
Once you have saved your script, you queue it for execution by running the following command:<syntaxhighlight lang="bash">
sbatch hello-slurm.sh
</syntaxhighlight>You should see output similar to this:<syntaxhighlight>
Submitted batch job 1928

</syntaxhighlight>Since the script does very little work it will probably execute immediately, but if it doesn't you can see its place in the queue by running the command <code>squeue</code>. You can also see details about your job by running <code>scontrol show job NN</code>, where NN is the job ID that was printed (1928 in this example).

=== Reading job output ===
Since the job is run asynchronously, the output from your job will not be printed to your terminal as usual but written to a file. We don't specify a filename to use, so slurm will use the default name. The default name is <code>slurm-NN.out</code>, where NN is the job ID.

You can read the resulting file with any tool that can read text files, such as <code>cat</code>:<syntaxhighlight lang="bash">
erth9960@slurm-login:~$ cat slurm-1928.out
Hello slurm-node-cpu-01

</syntaxhighlight>Here you can see that the code executed on <code>slurm-node-cpu-01</code>, as opposed to <code>slurm-login</code> which is where your terminal session is running.

Applying for access

2026-04-27T12:34:52Z

Erth9960(AT)su.se:

All requests for access are to be sent by email to '''slurmsupport (at) dsv.su.se'''.

=== Thesis students ===
If you are writing or intend to write your thesis and need access to Olympus, this is the process to follow.

# Produce a working proof of concept
# Ask your supervisor to request access to Olympus on your behalf
# Adapt your code to run on the cluster
# Run your experiment

==== Produce a working proof of concept ====
Running code on a cluster is not like running code on your own computer the way you may be used to. Your code is not run interactively, which makes debugging more difficult, and there is no guarantee that your code runs immediately when you submit a job. Because of this, it is crucial that you have a test bed somewhere else where you can test changes and validate your workflow ''before'' you attempt to run your code on the cluster. Usually this would mean setting up a smaller version of your experiment that you can run either on your own computer or in the computer labs. This proof of concept should remain your "testbed" for evolving your program once you start running your experiments on Olympus, since you are going to have a much easier time diagnosing any problems in that limited environment than on the full cluster.

As an example, if you want to run an image classification experiment where a machine learning model is to identify the number and species of birds in photographs, you might produce a version of your experiment which uses the smallest possible version of the machine learning model you intend to use, and feed it a single picture with a bird. This should be possible to run on most hardware, and you will be able to do any initial debugging of your program in this limited implementation. Once you have a working implementation of your program in this limited form, you are ready to move on to requesting access to Olympus.

In order to make things easier going forward, do your best to isolate the portions of your program that will need modifying when you scale up your experiment to the size that you intend to run on Olympus.

==== Ask your supervisor to request access to Olympus on your behalf ====
When your proof of concept is in place, you can ask your supervisor to request access to Olympus on your behalf. The information they will need to submit in order for you to be granted access is:

* A couple of sentences describing your experiment. This is to ensure that we can determine if Olympus is a good fit or if we will need to provide some other solution for your project.
* A rough estimate of resource needs in terms of CPU, RAM, VRAM and disk storage.
* The SU usernames of all authors for this thesis.

Access requests will be processed within a few working days of submission. If we determine that your project is unsuitable for Olympus (for example if it requires a very tight feedback loop or must run on Windows), we will work with you and your supervisor to provide an alternative solution. We have some machines in reserve for such projects.

==== Adapt your code to run on the cluster ====
In order for your code to be able to run on Olympus, you will need to write a wrapper script that informs Slurm of the resources your job needs, what program to run, where to store output, etc. Documentation for how to write this script will be written and published here shortly. Regardless of the state of the documentation at the time you write your script, you will likely run into issues that you need help sorting out. Contact slurmsupport for help with this or any other questions regarding Olympus.

When doing this adaptation work, you should make sure that your proof of concept stays up to date and is a representative minimal version of your experiment. This will help you sort out problems faster and easier than purely running your code on the cluster. Ideally the only difference between your on- and off-cluster code should be the size of the model you run and the amount of input it processes.

==== Run your experiment ====
Once you have your wrapper script in place and your proof of concept code works, you can run your experiment.

=== Other students ===
We are currently not offering Olypus access to students who are not writing their thesis.

=== Staff ===
Staff can apply for access by emailing slurmsupport.

Applying for access

2026-04-27T12:33:15Z

Erth9960(AT)su.se: Created page with "All requests for access are to be sent by email to '''slurmsupport (at) dsv.su.se'''. === Thesis students === If you are writing or intend to write your thesis and need access to Olympus, this is the process to follow. # Produce a working proof of concept # Ask your supervisor to request access to Olympus on your behalf # Adapt your code to run on the cluster # Run your experiment ==== 1. Produce a working proof of concept ==== Running code on a cluster is not like ru..."

All requests for access are to be sent by email to '''slurmsupport (at) dsv.su.se'''.

=== Thesis students ===
If you are writing or intend to write your thesis and need access to Olympus, this is the process to follow.

# Produce a working proof of concept
# Ask your supervisor to request access to Olympus on your behalf
# Adapt your code to run on the cluster
# Run your experiment

==== 1. Produce a working proof of concept ====
Running code on a cluster is not like running code on your own computer the way you may be used to. Your code is not run interactively, which makes debugging more difficult, and there is no guarantee that your code runs immediately when you submit a job. Because of this, it is crucial that you have a test bed somewhere else where you can test changes and validate your workflow ''before'' you attempt to run your code on the cluster. Usually this would mean setting up a smaller version of your experiment that you can run either on your own computer or in the computer labs. This proof of concept should remain your "testbed" for evolving your program once you start running your experiments on Olympus, since you are going to have a much easier time diagnosing any problems in that limited environment than on the full cluster.

As an example, if you want to run an image classification experiment where a machine learning model is to identify the number and species of birds in photographs, you might produce a version of your experiment which uses the smallest possible version of the machine learning model you intend to use, and feed it a single picture with a bird. This should be possible to run on most hardware, and you will be able to do any initial debugging of your program in this limited implementation. Once you have a working implementation of your program in this limited form, you are ready to move on to requesting access to Olympus.

In order to make things easier going forward, do your best to isolate the portions of your program that will need modifying when you scale up your experiment to the size that you intend to run on Olympus.

==== 2. Ask your supervisor to request access to Olympus on your behalf ====
When your proof of concept is in place, you can ask your supervisor to request access to Olympus on your behalf. The information they will need to submit in order for you to be granted access is:

* A couple of sentences describing your experiment. This is to ensure that we can determine if Olympus is a good fit or if we will need to provide some other solution for your project.
* A rough estimate of resource needs in terms of CPU, RAM, VRAM and disk storage.
* The SU usernames of all authors for this thesis.

Access requests will be processed within a few working days of submission. If we determine that your project is unsuitable for Olympus (for example if it requires a very tight feedback loop or must run on Windows), we will work with you and your supervisor to provide an alternative solution. We have some machines in reserve for such projects.

==== 3. Adapt your code to run on the cluster ====
In order for your code to be able to run on Olympus, you will need to write a wrapper script that informs Slurm of the resources your job needs, what program to run, where to store output, etc. Documentation for how to write this script will be written and published here shortly. Regardless of the state of the documentation at the time you write your script, you will likely run into issues that you need help sorting out. Contact slurmsupport for help with this or any other questions regarding Olympus.

When doing this adaptation work, you should make sure that your proof of concept stays up to date and is a representative minimal version of your experiment. This will help you sort out problems faster and easier than purely running your code on the cluster. Ideally the only difference between your on- and off-cluster code should be the size of the model you run and the amount of input it processes.

==== 4. Run your experiment ====
Once you have your wrapper script in place and your proof of concept code works, you can run your experiment.

=== Other students ===
We are currently not offering Olypus access to students who are not writing their thesis.

=== Staff ===
Staff can apply for access by emailing slurmsupport.

Main Page

2026-04-27T12:16:26Z

Erth9960(AT)su.se:

Main Page

2026-04-27T12:00:06Z

Erth9960(AT)su.se:

<strong>MediaWiki has been installed.</strong>

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for on using the wiki software.

== Getting started ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]