General

Singularity is software for creating and runningcontainers(similar to Docker, for example) that is specifically designed for scientific computing and HPC.Version 3.7.1 of Singularity is installed on the OMNI cluster.

To use Singularity, you must load the corresponding module (more on moduleshere):

module load singularity

You can find the Singularitydocumentation here. You can also use the command `singularity help` to view an overview of the most important Singularity commands.

On this page, you’ll find a brief explanation of the container concept as well as a quick overview of the tools available on the OMNI cluster for creating and running Singularity containers (including parallel execution via MPI).

The Container Concept

Containers are executable files that contain not only a program but also, as a rule, the software and software libraries the program needs to run (its so-calleddependencies). Unlike virtual machines, however, the hardware of the computer on which the container runs is not virtualized.

Singularity containers offer several advantages:

• Since the software and all dependencies are available in a known and unchanging version, thereproducibility of scientific results is improved.
• Since the container is a single file, it is easier toshare it with others and run it onother computers.
• Singularity supportsmultiple container formats, including Docker’s. By default, Singularity’s own.sifformat is used.
• Unlike Docker, you donot needroot access to run or create Singularity containers.

Creating Containers

There are several ways to obtain Singularity containers or create them yourself. All methods use the `singularity build` command, which is explained in detailhere.

• The first and easiest option is todownload a container from the Container Library, Singularity Hub, or another repository. Singularity also offers a way to convert Docker containers to the Singularity format.
• The second option is toconnect to a container viaSSHand install software manually.
• The third option is to write adefinition file for the container and create the container using that definition file.

You can sharefiles 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 describedhere.

Note: For security reasons, user namespaces had to be disabled on the cluster. As a result, the methods mentioned here work only with limitations, especially when the--fakerootoption is used. There are two workarounds for this:

• You can create the container on your own Linux PC (or a virtual machine running Linux) where you have root privileges or where the--fakeroot option works.
• You can use theonline build service provided by Sylabs, the company that developed Singularity.

In both cases, you must create a definition file. After creating the container, it can simply be copied to the cluster like any other file and then used there.

Running Containers

You can run a Singularity container just like any other executable file:

./.sif

Or with the following command:

singularity run 

This will execute the container’s so-calledrunscript. The runscript defines exactly what 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 documentationhere.

Warning: Like any other application, the container in this example will runon the login node. You should never run computationally intensive programs on the login node, since you share the login nodes with all other users. Normally, you should create ajob script in which you include the command `singularity run ...` (don’t forget to load the `singularity` module).

Parallel Execution

You can launch MPI applications in Singularity containers and can also configure containers so that multiple containers can communicate via MPI. The Singularity documentation explains two different variantshere, both of which are compatible with the OpenMPI installed on OMNI (already loaded as a module by default) as well as with SLURM. The difference between the two variants is that in one case only the host system’s MPI is used, while in the other variant (called the “Hybrid Model” in Singularity), MPI must be installed both inside and outside the container.