Skip to content

Quick Start

This section is intended as a brief introduction into HPC, especially to the present system UBELIX. This page is an summary, a hands-on introduction, which targets primarily users without prior knowledge in high-performance computing. However, basic Linux knowledge is a prerequisite. If you are not familiar with basic Linux commands, there are many beginner tutorials available online. After reading this page you will have composed and submitted your first job successfully to the cluster. Links are provided throughout the text to point you to more in-depth information on the topic.

Cluster Rules

Before we start: as everywhere where people come together, a common sense is needed to allow for a good cooperation and to enable a positive HPC experience. Be always aware that you are working on a shared system where your behaviour could have a negative impact on the workflow of other users. Please find the list of the most important guidelines in our code of conduct.

Request an Account

Before you can start working on the HPCs, staff and students of the University of Bern must have their Campus Account (CA) registered for the HPCs. External researchers that collaborate with an institute of the University of Bern must apply for a CA through that institute. See Accounts and Activation for more information getting access to UBELIX.

HPC Workspace

Workspaces provide are a collaborative environment, including group based access to permanent and temporary storage, as well as group based compute resource accounting. Research group leaders need to apply for an workspace.


To connect to the cluster, you must log in to a login node from inside the university network (e.g. from a workstation on the campus). If you want to connect from a remote location (e.g. from your computer at home) you must first establish a VPN connection to get access to the university network. To connect from a UNIX-like system (Linux, Mac OS X, MobaXterm on Windows) use a secure shell (SSH) to log in to a login node. There are four login nodes (submit[01-04], you can pick any one:

# here we choose as our login node
ssh <user>

Welcome $HOME

After successful login to the cluster, your will find yourself in the directory /storage/homefs/$USER, where $USER is your Campus Account username. This is your home directory and serves as the repository for your personal files, and configurations. You can reference your home directory by ~ or $HOME.

Your home directory is located on a shared file system. Therefore, all files and directories are always available on all cluster nodes and must hence not be copied between those nodes. HOME directories have a daily snapshot and backup procedures. Disk space is managed by quotas. Each user has 1TB of disk space available. Keep your home directory clean by regularly deleting old data or by moving data to a private storage.

You can always print the current working directory using the pwd (present working directory) command:


Copy Data

At some point, you will probably need to copy files between your local computer and the cluster. There are different ways to achieve this, depending on your local operating system (OS). To copy a file from your local computer running a UNIX-like OS use the secure copy command scp on your local workstation:

scp /path/to/file <user>

To copy a file from the cluster to your local computer running a UNIX-like OS also use the secure copy command scp on your local workstation:

scp <user> /path/to/target_dir/

More information about file transfer can be found on the page File Transfer to/from UBELIX.

Use Software

On our HPCs you can make use of already pre-installed software or you can compile and install your own software. We use a module system to manage software packages, even different versions of the same software. This allows you to focus on getting your work done instead of compiling software. E.g. to get a list of all provided packages:

module avail

Workspace software stacks

module spider or module avail will only find packages in a Workspace software stack if the Workspace module for that workspace is loaded

Furthermore, we suggest to work with so called toolchains. These are collections of modules build on top of each other.

To set the environment for a scientific application with Python, load:

$ module load Anaconda3
$ eval "$(conda shell.bash hook)"

To set the environment for compiling a scientific application with math libraries, OpenMPI and GCC, load:

$ module load foss
$ module list

Currently Loaded Modules:
  1) GCCcore/12.3.0                          9) OpenSSL/1.1                      17) OpenBLAS/0.3.23-GCC-12.3.0
  2) binutils/.2.40-GCCcore-12.3.0     (H)  10) UCX/1.14.1-GCCcore-12.3.0        18) FlexiBLAS/3.3.1-GCC-12.3.0
  3) GCC/12.3.0                             11) libfabric/1.18.0-GCCcore-12.3.0  19) FFTW/3.3.10-GCC-12.3.0
  4) numactl/2.0.16-GCCcore-12.3.0          12) zlib/1.2.13-GCCcore-12.3.0       20) gompi/2023a
  5) XZ/.5.4.2-GCCcore-12.3.0          (H)  13) libevent/2.1.12-GCCcore-12.3.0   21) FFTW.MPI/3.3.10-gompi-2023a
  6) libxml2/.2.11.4-GCCcore-12.3.0    (H)  14) PMIx/4.2.4-GCCcore-12.3.0        22) ScaLAPACK/2.2.0-gompi-2023a-fb
  7) libpciaccess/.0.17-GCCcore-12.3.0 (H)  15) UCC/1.2.0-GCCcore-12.3.0         23) foss/2023a
  8) hwloc/2.9.1-GCCcore-12.3.0             16) OpenMPI/4.1.5-GCC-12.3.0

   H:  Hidden Module


The loaded version of a software is only active in your current session. If you open a new shell you are again using the default version of the software. Therefore, it is crucial to load the required modules from within your job script.

But also keep in mind that the current environment will get forwarded into a job submitted from it. This may lead to conflicting versions of loaded modules and modules loaded in the script.

The Software section is dedicated to this topic. More information can be found there.

Managing different working environments can be done with “Meta Modules” or user collections, see Environment Definitions

Hello World

Currently you are on a submit server also known as login node. This server is for preparing the computations, i.e. downloading data, writing a job script, prepare some data etc. But you are not allowed to run computations on login nodes! So, you have to bring the computations to the compute nodes - by generating a job script and sending it to the cluster.

Working interactively on a compute node

When developing stuff it’s often useful to have short iterations of try-error. Therefore it’s also possible to work interactively on a compute node without having to send jobs to the cluster and wait until they finish just to see it didn’t work. See Interactive Jobs for more information about this topic.

To do some work on the cluster, you require certain resources (e.g. CPUs and memory) and a description of the computations to be done. A job consists of instructions to the scheduler in the form of option flags, and statements that describe the actual tasks. Let’s start with the instructions to the scheduler:

#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=1GB

# Put your code below this line

The first line makes sure that the file is executed using the bash shell. The remaining lines are option flags used by the sbatch command. The page Jobs Submission outlines the most important options of sbatch.

Now, let’s write a simple “hello, world”-task:

# Put your code below this line
module load Workspace_Home
echo "Hello, UBELIX from node $(hostname)" > hello.txt

After loading the Workspace module, we print the line Hello, UBELIX from node <hostname_of_the_executing_node> and redirect the output to a file named hello.txt. The expression $(hostname) means, run the command hostname and put its output here. Save the content to a file named

The complete job script looks like this:

#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=1GB

# Put your code below this line
module load Workspace_Home
echo "Hello, UBELIX from node $(hostname)" > hello.txt

Schedule Your Job

We can now submit our first job to the scheduler. The scheduler will then provide the requested resources to the job. If all requested resources are already available, then your job can start immediately. Otherwise your job will wait until enough resources are available. We submit our job to the scheduler using the sbatch command:

Submitted batch job 32490640
If the job is submitted successfully, the command outputs a job-ID with which you can refer to your job later on. There are various options for different types of jobs provided in the scheduler. See sections Array Jobs, GPUs, and Interactive Jobs for more information

Monitor Your Job

You can inspect the state of our active jobs (running or pending) with the squeue command:

squeue --job=32490640
   32490640     epyc2    job01 testuser  R       0:22      1 bnode23

Here you can see that the job ‘job01’ with job-ID 32490640 is in state RUNNING (R). The job is running in the ‘epyc2’ partition (default partition) on bnode23 for 22 seconds. It is also possible that the job can not start immediately after submitting it to SLURM because the requested resources are not yet available. In this case, the output could look like this:

squeue --job=32490640
    32490640     epyc2    job01 testuser PD       0:00      1 (Priority)

Here you can see that the job is in state PENDING (PD) and a reason why the job is pending. In this example, the job has to wait for at least one other job with higher priority.

You can always list all your active (pending or running) jobs with squeue:

squeue --me
   34651451     epyc2  testuser PD       0:00      2 (Priority)
   34651453     epyc2  testuser PD       0:00      2 (Priority)
   29143227     epyc2     Rjob  testuser PD       0:00      4 (JobHeldUser)
   37856328       bdw  testuser  R       4:38      2 anode[012-014]
   32634559       bdw  testuser  R    2:52:37      1 anode12
   32634558       bdw  testuser  R    3:00:54      1 anode14
   32634554       bdw  testuser  R    4:11:26      1 anode08
   32633556       bdw  testuser  R    4:36:10      1 anode08

Further information on on job monitoring you find on page Monitoring Jobs. Furthermore, in the Job handling section you find additional information about Investigating a Job Failure and Check-pointing.