General information

Singularity is a software for creating and running containers (similar to Docker, for example) that is particularly geared towards scientific computing and HPC. Singularity is installed on the OMNI cluster in version 3.7.1.

To use Singularity, you must load the corresponding module (more about modules here):

module load singularity

The Singularity documentation can be found here. You can also use the singularity help command to display an overview of the most important Singularity commands.

On this page you will find a brief explanation of the container concept as well as a short overview of the tools available on the OMNI cluster for creating and executing Singularity containers (including parallel execution using MPI).

The container concept

Containers are executable files that not only contain a program, but usually also the software and software libraries that the program needs to run (its so-called dependencies). In contrast to virtual machines, however, the hardware of the computer on which the container is running is not virtualized.

Singularity containers have several advantages:

• Since the software and all dependencies are available in a known and unchangeable version, the reproducibility of scientific results is increased.
• As the container is available as a single file, it is easier to share it with other people and start it on other computers.
• Singularity supports several container formats, including that of Docker. Singularity's own .sif format is used by default.
• Unlike Docker, you do not need root access to run and create Singularity containers.

Creating containers

You have several options for obtaining Singularity containers or creating them yourself. All methods use the singularity build command, which is explained here
is explained in detail here.

• The first and easiest way is to download a container from the Container Library, the Singularity Hub or another repository. Singularity also offers a way to convert Docker containers into the Singularity format.
• The second is to dialinto a container using ssh
  and install software there manually.
• The third option is to write a definition file
  for the container and create the container using this definition file.

You can share files and directories between the container and the host system (i.e. the computer on which the container is running) in several ways. The two most important are so-called bind paths and mounts, which are described here.
are described here.

Attention: For security reasons, user namespaces had to be deactivated on the cluster. This means that the methods mentioned here only work with restrictions, especially if the --fakeroot option is used. There are two workarounds for this:

• You can build the container on your own Linux PC (or virtual machine running Linux) where you have root privileges or the --fakeroot option works.
• You can use the online build service
  from the Singularity manufacturer Sylabs.

In both cases, a definition file must be created. Once the container has been created, it can simply be copied to the cluster like any other file and then used there.

Executing containers

You can simply execute a Singularity container like any other executable file:

./.sif

Or with the following command:

singularity run 

This will execute the so-called runscript of the container. The runscript defines what exactly happens when the container is executed. If you create a container yourself, you must also create this runscript yourself, usually as part of the definition file. Details on runscripts in definition files can be found in the Singularity documentation here.

Attention: Like any other application, the container in this example will run on the login node. You should never run compute-intensive programs on the login nodes, as you share the login nodes with all other users. Normally, you should create a job script
in which you insert the command singularity run ... command (do not forget to load the singularity module).

Parallel execution

You can start MPI applications in Singularity containers and can also set up containers so that several containers can communicate via MPI. The Singularity documentation explains here
two different variants, both of which are compatible with the OpenMPI installed on the OMNI (already loaded as a module by default) and with SLURM. The difference between the two variants is that in one case only the MPI of the host system is used, while in the other variant (called "Hybrid Model" in Singularity), an MPI must be installed both inside and outside the container.