Frequently Asked Questions - "Software"

Frequently Asked Questions – Software


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.

Our module system is built in form of a hierarchical tree with respect to compiler(s) and MPI version(s). Many (open source) software package thus don't appear in the first instance, and become available only until you load a (suitable) compiler (and a (suitable) MPI module, respectively.

In case you didn't load one or the other yet, many packages don't show up in the output of “module avail”.

If you seem to miss a required software, please try

module spider <mySW> oder
module spider | grep -i mySW oder
module --show-hidden avail <mySW>

before installing it yourself or opening a ticket.

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 first have to check whether the software requires a license. In that case, you have to prove you have the rights to use (a sufficient amount of) it, for example if your institute/department contributes to the yearly costs of a TU license, or has purchased its own.

Please read also the comments to licenses in this list.

In general: everything possible is not everything allowed.

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.

Runtime Issues

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 -Sc 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

Yes, that's possible, by using the so-called “collection” feature of our module system LMod.

More details can be found in our Tips and Tricks section, and inside “man module”.

Machine Architecture

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).


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.