ALERT! Warning: your browser isn't supported. Please install a modern one, like Firefox, Opera, Safari, Chrome or the latest Internet Explorer. Thank you!
Startseite » ... » Zentrale Einrichtungen  » ZIH  » Wiki
phone prefix: +49 351 463.....

HPC Support

Operation Status

Ulf Markwardt: 33640
Claudia Schmidt: 39833

Login and project application

Phone: 40000
Fax: 42328

You are here: Compendium » RuntimeEnvironment

Runtime Environment

Make sure you know how to work with a Linux system. Documentations and tutorials can be easily found in the internet or in your library.


To allow the user to switch between different versions of installed programs and libraries we use a module concept. A module is a user interface that provides utilities for the dynamic modification of a user's environment, i.e., users do not have to manually modify their environment variables ( PATH , LD_LIBRARY_PATH, ...) to access the compilers, loader, libraries, and utilities.

For all applications, tools, libraries etc. the correct environment can be easily set by e.g. module load maple. If several versions are installed they can be chosen like module load matlab/2007a. A list of all modules shows module avail. Other important commands are:

Command DescriptionSorted ascending
module avail list all available modules
module list list all user-installed modules
module load <modname> load module modname
module purge remove all user-installed modules
module help show all module options
module switch <mod1> <mod2> unload module mod1 ; load module mod2
module rm <modname> unloads module modname
Module files are ordered by their topic on our HPC systems. By default, with module av you will see all available module files and topics. If you just wish to see the installed versions of a certain module, you can use module av softwarename and it will display the available versions of softwarename only.

Lmod: An Alternative Module Implementation

Historically, the module command on our HPC systems has been provided by the rather dated Environment Modules software which was first introduced in 1991. As of late 2016, we also offer the new and improved LMOD as an alternative. It has a handful of advantages over the old Modules implementation:
  • all modulefiles are cached, which especially speeds up tab completion with bash
  • sane version ordering (9.0 < 10.0)
  • advanced version requirement functions (atleast, between, latest)
  • auto-swapping of modules (if a different version was already loaded)
  • save/auto-restore of loaded module sets (module save)
  • multiple language support
  • properties, hooks, ...
  • depends_on() function for automatic dependency resolution with reference counting
Which modules implementation will be used is decided upon the presence of a file named .no-lmod in a user's home directory. Lmod is the default but you can fall back on the vanilla modules if you create ~/.no-lmod (you have to re-login to make changes take effect).

Module Environments

On Taurus, there exist two different module environments, each containing a set of software modules. The first one is the "classic" environment which is already loaded by default and where you will find most of our manually installed software. Then we have another environment which contains modules that have been built more or less automatically using EasyBuild ("eb" for short).

Depending on whether you use LMOD or the original Modules implementation, there are different ways to switch between these module environments. For LMOD, they are called "modenv/classic" and "modenv/eb", one of which should always be loaded and is therefor marked as sticky. For the original Modules, one can just load "eb", and unload it again to switch back to the classic environment.
  • for Lmod users (recommended):
$ module load modenv/eb

The following have been reloaded with a version change:
  1) modenv/classic => modenv/eb

$ module avail
#... EasyBuild modules will be listed

$ module load modenv/classic

The following have been reloaded with a version change:
  1) modenv/eb => modenv/classic
  • for users of the vanilla Modules:
$ module load eb
Switching to EasyBuild modules environment.

$ module avail
#... EasyBuild modules will be listed

$ module unload eb
Switching back to classic modules environment.

While it is possible to have modules loaded from both environments at the same time, in some cases there might be naming conflicts, so only do this with caution and if you know what you are doing.

Private User Modules Files

Private modules files allow you to load your own installed software into your environment and to handle different versions without getting into conflicts.

You only have to call module use <path to your module files>, which adds your directory to the list of module directories that are searched by the module command. Within the privatemodules directory you can add directories for each software you whish to install and add within this directory a modules file for each version you have installed. Further information about modules you can find at .

This is an example for a private modules file:
dolescha@venus:~/module use $HOME/privatemodules

dolescha@venus:~/privatemodules> ls
null  testsoftware

dolescha@venus:~/privatemodules/testsoftware> ls

dolescha@venus:~> module av
------------------------------- /work/home0/dolescha/privatemodules ---------------------------
null             testsoftware/1.0

dolescha@venus:~> module load testsoftware
Load testsoftware version 1.0

dolescha@venus:~/privatemodules/testsoftware> cat 1.0 
##     testsoftware modulefile
proc ModulesHelp { } {
        puts stderr "Loads testsoftware"

set version 1.0
set arch    x86_64
set path    /home/<user>/opt/testsoftware/$version/$arch/

prepend-path PATH            $path/bin
prepend-path LD_LIBRARY_PATH $path/lib

if [ module-info mode load ] {
        puts stderr "Load testsoftware version $version"

Private Project Modules Files

Private modules files allow you to load your group-wide installed software into your environment and to handle different versions without getting into conflicts.

The module files have to be stored in your global projects directory /projects/p_projectname/privatemodules. An example for a module file can be found in the section above.

To use a project-wide module file you have to add the path to the module file to the module environment with following command module use /projects/p_projectname/privatemodules.

After that, the modules are available in your module environment and you can load the modules with module load .


An automated backup system provides security for the HOME-directories on Taurus and Venus on a daily basis. This is the reason why we urge our users to store (large) temporary data (like checkpoint files) on the /scratch -Filesystem or at local scratch disks.

Please note: We have set ulimit -c 0 as a default to prevent you from filling the disk with the dump of a crashed program. bash -users can use ulimit -Sc unlimited to enable the debugging via analyzing the core file ( limit coredumpsize unlimited for tcsh ).