This page is still under construction

From time to time, we will revise and edit this web page.

Please send us your question via email to , and if question & answer are of general interest, we will amend this FAQ accordingly.

Globally installed programs

You can list all installed programs and versions with the command module avail. The command module loads and unloads paths and environmental variables as well as it displays available software. A detailed description is available here.

Please send us an email . If the requested program is of interest to several users or groups, we will install it in our module tree to make it available for all. Otherwise we will support you (to a certain extent) in attempting a local installation, eg. in your /home/ folder.


No, you have to proof if the software requires a license and if you have the rights to use it, for example if your department contributes to the yearly costs of a TU license. Please read also the comments to licenses in this list.

In general not everything is allowed, what is possible.

It depends. In general, our modules for commercial software fetch their licenses from license servers of the TU Darmstadt. These licenses are dedicated exclusively for members of TU Darmstadt contributing to the license costs. Please send us an email to if you have license questions. We can support you in configuring your software to fetch license tokens from eg. your institute's license servers.

In general not everything is allowed, what is possible.

Software and runtime problems

Remove all unnecessary modules. A job script should always start with

module purge
module load <only modules really required for this job>

to ensure a clean environment:.

Remember: whenever you load modules while you are on a login node, any job submitted from this modified environment will inherit these modules' settings!
Therefore, it is strongly recommended to use the above purging/loading statement in all job scripts.

Next, scrutinize your program's runtime libraries (“shared objects”) with

ldd -v /path/to/binary

Your $LD_LIBRARY_PATH might contain an unwanted directory, causing your program to load wrong or outdated libraries, which in fact should rather be coming from the modules you have loaded.

Particularly, the infamous“Bus error” can be caused by non-matching arguments or return values between calling binary and called library, thus causing “unaligned” memory access and crashes.

A crashing program usually causes a memory dump of its process to be created (in Linux, a file called core.<PID> in the directory where the program was started).

Unfortunately, some user jobs repeatedly crashed in a loop, causing lots of coredumps being created on our cluster-wide GPFS filesystem. As this adversely affected its performance and availability, we had to switch off the creation of coredumps by default.

However, for you to debug your software, we didn't prohibit core dumps entirely, and thus writing them can be enabled again:

ulimit -c unlimited
<my crashing program call>
gdb /path/to/programBinary core.<PID>

If it is in fact the very same binary (and not only the same “program”), compare together

  • your job scripts
  • the modules you have loaded before submitting the job:
    module list
    (because these are inherited to the job!)
  • your respective shell environment:
    env | sort > myEnv
  • your respective $LD_LIBRARY_PATH setting and the libraries effectively loaded at runtime:
    ldd /path/to/same/binary

The Lichtenberg HPC runs only Linux, and thus will not run windows (or MacOS) executables natively.

Ask your scientific software vendor or provider for a native Linux version: if it is in fact a scientific application, there's a very good chance they have one…

Due to the unproportional administrative efforts (and the missing windows licenses), we are sorry to have to deny all requests like “virtual windows machines on the cluster” or to install WINE just like that.

Since the Lichtenberg HPC runs CentOS (a RedHat compatible distribution), the native application packaging format is RPM, not .deb.

Though there are ways to convert .deb packages to .rprm or even to install .deb on RPM-based distributions (see the “alien” command's information on the web), we cannot support installing or even converting them. Check with the vendor/supplier to get .rpm packages, or try and compile the program yourself (if the source code is available).