Consistent software provisioning (esp. research applications) on Linux
Overview
Since Linux workstations and compute servers at the institute are centrally managed by IT and installing computers is a highly automated process we can guarantee that all institute computers behave identically. The IT department prioritizes software consistency to ensure reproducibility of research results. Each computer is assigned a software platform generation upon installation, and IT strives to prevent abrupt changes. The supported software for each software platform generation is listed at
SoftwareLinux. If you need new software or different versions, please
submit a ticket. You are allowed to install software
by yourself. This pages wants to shine some light on the details and concepts of software deployment in the institute.
The operating system is identified by a generation number being eight as of October 2025. Be aware that only the most up-to-date software platform generation is available for newly installed computers. This explicitly includes computers that have to be re-installed because of broken hard disks.
No computation software will simply disappear one day on a given platform. However, a software package might be no longer be supported on the next platform generation. IT minimizes changes to software configurations within a generation, so no computation software will get major upgrades. There are some exceptions, especially for programs with high attack surface:
- Office programs (e.g. LibreOffice)
- Web browsers (e.g. Firefox)
These programs are not considered critical when it comes to reproducibility of computation results. Packages are pre-installed with unique IDs and version numbers, which IT strives to keep consistent across all machines within a generation. Updates to critical packages (e.g. an FFT library) are limited to security updates and bug fixes without introducing new behavior.
How software is brought to you as a user
This section explains the specific ways to run research software at the institute. For a birds-eye view comparing the methods and suggestion ways forward, go to
#deciding
Software installed directly on computers
A lot of software (incl. scientific software) is available for quick installation directly on computers. If you e.g. want a specific favorite text editor of yours, please
contact us and we'll make it work. However, no software installation can be done by users since we have to consider side effects with other users when choosing, how to do it.
Software installed in the network
Permanent Link:

Installing multiple versions of software on a single computer can be complex, since it's important to ensure users are not surprised e.g. by sudden version changes which would break reproducibility. For that we often refrain from installing a package locally but use one of two concepts of installing it on the network.
Two methods are used in the institute for network-installed software:
- Packages installed in network locations:
- Multiple versions are available, accessed via command line.
- Enable the software (possibly selecting a version), then use its commands.
- For Matlab, use
MATLAB or MATLAB --version 9.12 to enable, then matlab to run.
- The
matlab command alone runs the latest version.
- Since this is a research institute, flexibility regarding software installation is necessary. This is what personal storage blocks (e.g. /data/u_someuser_software) are for. Feel free to request one and install software there. These storage blocks are guaranteed to be accessible only by one user.
- Containerized software:
- Software is packaged with its platform in a container to reduce adaptation effort.
- We use Singularity for that.
- Access containerized software with the
sc command, e.g., sc fsl for different versions, learn more here.
Environments
Permanent Link:

In Unix it's common to use one tool per task. The institute's environment concept lets you pick tool versions independently from each other, based on
#networksoftware.
Remember: Activate the environment each time you need it.
Example:
How should I run research software at the institute?
Permanent Link:

Scientific computing usually involves writing scripts which in turn call specific commands in common scientific software packages. This is then considered a "pipeline", combining different steps which are run on several data sets (e.g. test subject brain measurements).
First have a look at which scientific software is available at the institute:
https://topic.cbs.mpg.de/softwarelinux . This page shows the available deployment types per version per software package per generation. If you miss anything there, consider
contacting IT - it might be quite easy to add it.
You're allowed to install software by yourself. Possible ways include
https://topic.cbs.mpg.de/conda - which is encuraged, if you want to build complex environments including lots of research software packages. Make sure, not to install software into your home directory.
Try to work with the
#sc or
#scwrap deployment types as much as possible. Both concepts provide a frozen view on the respective software which makes reproducibility and juggling different scientific software packages super-easy. Here are some examples:
Scenario 1: You received a more or less complex script which requires "Convert 3D" and ANTS. You don't want to modify it.
#!/bin/bash
# scriptname: script1.sh
c3d parameter 1 parameteqr2 ...
antsMotionCorrStats parameter1 parameter2
...
Disussion:
- The script requires commands of different software packages to "just be available". This has to be done using #scwrap.
- You have to (from the scripts point of view) externally enable these commands and choose the right version(s) via the
SCWRAP wrapping tool.
- Two packages have to enabled in the example (ants and itksnap, which contains the c3d tool). There's no limit to the number of packages that can be enabled by scwrap at a given time.
- If you run the script without
SCWRAP , the c3d and antsMotionCorrStats commands won't be found and an error will be thrown.
- Example use of the script:
user@host > SCWRAP ants latest SCWRAP itksnap latest script1.sh
You might want to put the wrapper call into a another script or into a shell alias.
- Reproducible way of using the script (since the
latest version will change over time; numeric ones will not):
- Find out, which version of
ants and itksnap is recent by typing SCWRAP ants and SCWRAP itksnap respectively.
- Explicitely run the script with some these versions. Example:
user@host > SCWRAP ants 2.6.0 SCWRAP itksnap 4.2.2 script1.sh
- To run the script in the Institute's compute cluster, is has to be called like in the example use above (with all the SCWRAPs in front of it).
Scenario 2: You wrote a script by yourself and have control over the the commands called in there.
#!/bin/bash
# scriptname: script2.sh
# Which package versions to use
itksnapversion=4.2.2
antsversion=2.6.0
sc itksnap $itksnapversion c3d parameter 1 parameteqr2 ...
sc antsversion $antsversion antsMotionCorrStats parameter1 parameter2
# This one command should be run with an older version of ants explicitely:
sc antsversion 2.3.5 antsMotionCorrStats parameter1 parameter2
Discussion:
- This is the recommended way of doing things.
- Package version information are contained in the script itself - perfectly documented and potentially revision controlled.
- Multiple versions of the same scientific package can be used in a single script.
- The script can be run as-is on the institute's compute cluster
The sc/scwrap concept is not limited to shell scripts. The same concept works in python, matlab, make, etc. However, shell scripts are in most cases the best way to control your computation workflow. Avoid Matlab for this purpose since it requires subtil changes to the library environment and disturb/destroy reproducibility.
Scenario 3: You want to work with Python scripts using ants and convert3d in an IDE (e.g. Spyder or VS Code)
Discussion:
- You have to wrap Spyder as well to make this work.
- Example call:
user@host > SCWRAP ants 2.6.0 SCWRAP itksnap 4.2.2 spyder
- All programs run by Spyder (e.g. python scripts) will be inside the scwrap environment and have access to the respective commands.
Scenario 4: You want to use
script1.sh again turn to Conda instead of sc/scwrap
The Conda environment needs to be prepared:
user@host > install-conda
user@host > conda create -n ants_and_c3d
(ants_and_c3d) user@host > ca ants_and_c3d
Convert3D is a separate package here.
(ants_and_c3d) user@host > conda install convert3d=1.4.2 ants=2.6.0
(ants_and_c3d) user@host > script1.sh
Discussion:
- Apart from the
install-conda -script (which makes sure, Conda plays nicely in the institute), this method works outside the institute as well. This includes your private laptop.
- IT doesn't have control over available package versions in Conda. They could be removed at some point. sc/scwrap releases are frozen and stored forever.
- The choice of software in Conda is way bigger than deployed software in the institute. More complex environments can easily be built.
- To run the script in the Institute's compute cluster, the correct Conda environment needs to be enabled. Example:
conda run -n ants_and_c3d script1.sh
FAQ
I need the version number of a package on a certain computer in the past. What can I do?
IT stores historical package version records for several years. If you need to know the version number of a package on a certain computer in the past, please
write a ticket.
Which generation does computer X belong to?
1. A workstation before login:
For quick identification, the wallpaper of the login screen is identical on all workstations in the same generation.
2. The workstation, you're logged into:
Type this command into a shell:
user@host > distri -g
It will show the numerical
#generation of the computer.
3. A remote compute server:
When logging into a computer via
ssh or
getserver -s , the generation number is always shown (look at "OS:"):
I: Connecting via SSH to 'silbermond'
Linux silbermond 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64
_ This is a Interactive compute server
(v) OS : Generation 7, Kernel: 5.10.0-28
//_\\ Hardware : 376.57 GiB, 32x3600 bMIPS, CPU: Xeon Silver 4108 1.80GHz
(U_U) Where : C-20/rack2:35-38
Services : ComputeLinuxDedicated
_
/ \ This server is restarted 7am on the 1st Wednesday each month.
/ ! \
/_____\
It you're already logged in, the
distri -g command will work as well.
4. In a script:
It's good practice in programs to test their environment for assumptions. To test, if a script is running on a generation 7 computer, put this line at the beginning:
distri -g | grep -qw 7 || exit 1
What do CAPITALLETTERS+ (e.g. R+) commands do?
These commands are
environment wrappers that change the version selection of locally installed packages. Apart from that, they behave identical to other environment wrappers.
Example:
- R is sometimes installed directly on computers (because other packages depend on it).
- The R release installed locally is usually very old and you'd have a hard time, installing recent extensions on it.
- Most researchers in the institute use
R+ — an environment and therefore the possibility to either select a specific or more recent version.
- To run a recent version of R, instead of just
R , you'd type R+ R .
sc: What ist that?
Permanent Link:

Singularity is a concept of packaging a mini-operating system and some software into a compressed file (called a "singularity image file") which can then be run with a high degree of independence from the actual operating system.
Example use case: A piece of research relevant software was made ten years ago which requires an obscure library that has been abandoned for a long time. An old OS, the software and the library can be packaged into a singularity image file which can then be used easily for the foreseeable future.
sc is a small script specific to the MPI/CBS which eases integration of IT provided singularity image files into the institute's infrastructure.
In short: You could run singularity by yourself circumventing
sc . However, you should always use
sc if possible since it gives IT more control and ways to fix common problems centrally.
sc: How to use Singularity software?
Some software packages are provided as images for
software containers". These packages can be used via the
sc command.
The physical location of the container repository "somewhere on the network" However, you don't need to know that, and you should not use these containers without the
sc command.
To use a software package, you need the ID e.g.
fsl. There are some commands that will come in handy:
This will show available versions of a given containerized software package:
user@host > sc fsl
This will start a shell in the the latest available FSL container environment:
user@host > sc fsl latest
This will start a shell in a specific FSL container environment:
user@host > sc fsl 6.0.4
This will start a command in the containerized environment (a version can be given instead of
latest ):
user@host > sc fsl latest eddy_cuda9.1 ...
You have access to all storage resources of the institute in a container. Example:
user@host > sc fsl latest ls -la /afs/cbs.mpg.de /data/dt_transfer
To combine multiple software packages easily, there's an extension to the sc method available. Find more information
here. With sc a multi-software script would look like this:
#!/bin/bash
# Good scientists abort computations upon unexpected problems
set -e
## We define some variables to not have to type so much per command.
## The easy way:
#fsl="sc fsl latest"
#ants="sc ants latest
## The more scientific way with increased reproducibility:
fsl="sc fsl 6.0.6"
ants="sc ants 2.3.5"
cd /data/pt_12345/data
$fsl eddy_cuda9.1 ...
$ants antsRegistration ...
$fsl some_fsl_command ...
...
A script like that can operate on all
/data folders. Each call of the
sc command will spawn a small virtual environment, do its job and give control back to the script to run the next command.
SCWRAP: How to combine commands in differente Singularity containers?
Sometimes is easier to be able calling commands of a software package without having to add a prefix like
sc fsl latest . This is what
SCWRAP is for. Here are die ideas behind it:
- Each respective software package is installed in a container image.
- Each software package provides command line tools.
- The command line tools are duplicated outside the container and wrapped in a way that each invocation will run the respective command in the correct container.
This is how the example script in
#sc would look like with SCWRAP being used:
#!/bin/bash
# Good scientists abort computations upon unexpected problems
set -e
cd /data/pt_12345/data
eddy_cuda9.1 ...
$ants antsRegistration ...
some_fsl_command ...
...
To run it, wrappers are being used:
user@host > SCWRAP fsl 6.0.6 SCWRAP ants 2.3.5 myscript.sh
Jupyter
Find information about Jupyter use at the institute at
SoftwareJupyter .
How to install software by myself?
This is possible and encouraged but there are constraints. IT is very strict about software installation whenever installing it requires administrative permissions. One important reason is that with such permissions changes to a computer's software setup might have subtle influences on other users. However, software installation can be as easy as unpacking a zip file into a folder and running a program in it. When it comes to research related software, this is perfectly fine.
Depending on the context, you want to use the software in, you should choose a good location to install your software. Each user can get a
personal storage block to install and customize software in.
Hints/Warnings:
- Do not install security sensitive software by yourself. This explicitly includes
- interactive software communicating over the internet (e.g. Web browsers)
- software parsing complex data types (PDF editors)
- If the software you want to install is relevant for a bigger group of people, contact IT and ask for it to be installed at a central location. This will safe time and prevent some common problems.