Get started

The software pool is ready to be used under a version control system called environment modules. It is made for a user friendly activation and deactivation of software and allows to have several versions of the same software package installed in parallel at non-default places. "loading a module" can be thought as synonymous for "making software accessable". The most important commands to know are:

       module avail
       module help <package>/<version>       
       module load <package>/<version>
       module unload <package>/<version>

Loading a module manipulates the shell environment to make software visible for shell commands. Note, these changes of environmental variables are fully reversible and are taken back, if a module is unloaded. Loading a module may prepend the path to the binaries of a software package to environment variable PATH. This makes executables of software packages visible for the shell. For example, if you want to work with gcc, version 9,, load the appropriate module.

       module load gcc/9.3.0
       gcc --version      

Note, the system compiler gcc is invisible to your shell as long as the module gcc is loaded, but becomes available again, if the module gcc is unloaded.

To learn more, please read the Modules home page . There are also man-pages for module and modulefile. 

A list of all available modules sorted into CATEGORIES can be generated with the command module avail. A list of loaded modules is shown with the command module list. When you get a user account, your environment is provided by the system profile and should be set up correctly to use modules. If you change shell or modify your environment in such a way to make modules fail, contact the your consultant for help.

Module commands

Module commands usage

Module commands can be issued

• on the command line. This modifies the current shell environment, i.e., make selected binaries visible and defines environment variables to support compiling and linking. These modification are reversible and taken back when unloading a module.
• in batch scripts. This can be used to prepare the environment for jobs.

It is also possible to put module commands in the .bashrc. However, this may result in various conflicts and errors. So just: don't!

A complete list of all module commands is available with module help.Below, a few examples are introduced.

Available modules overview

       module avail

This command shows all modules available to be loaded.  Notice the version numbers and that some are marked as default. Modules makes it easy to switch between different software versions. The modules are sorted into CATEGORIES (all capital letters).

       module apropos String

This command seeks  through  the  so-called whatis  informations  of  all  available modulefiles for the specified string.  All module whatis informations matching the string search for *String* (case sensitive) will be displayed. Use the parameter *-i* to ignore case sensitivity. 

Load and unload modules

       module load <package>/<version>
       module unload <package>/<version>
       module switch <package>/<version1> <package>/<version2>

If you load the generic name of a module, you will get the default version. Loading a module manipulates the shell environment to make software visible for shell commands. Note, these changes of environmental variables are fully reversible and are taken back, if a module is unloaded. For example the path to a specific software can be prepended to PATH. To see all currently loaded modules, use

       module list

The modules command can also be used to manipulate environment variables directly. This is reversible and more save than manipulating the environment "by hand".

       prepend-path VAR val 
       append-var VAR val       
       remove-path VAR val

change the environment variable VAR without loading any module file. 

Getting module details

To investigate details of a module the commands

       module whatis <package>/<version> 
       module help <package>/<version>       
       module show <package>/<version>
       

Especially module show delivers information on the modified environment variables.

Use own module files

                 module load use.own

This command modifies the modules environment itself and adds $HOME/privatemodules to the path, where available modulefiles are searched for. Here you may place your own modulefiles to streamline a private software pool. It is also possible to manage the environment variable for different tasks this way. It is wise to use existing module files as template.

Compiling and linking installed libraries using modules

Many software packages depend on installed libraries like the MPI-libraries, fftw3, blas, netcdf or hdf5. On a PC, those libraries and headers would reside at well defined places in the system, where the are found by the compiler and linker and also by the loader during runtime. Several versions of those libraries are available. They must be installed at non-default places. So compiler, linker and loader need help to find them, especially the correct version. The dream of software users is that loading a module is all to be done to deliver this help. Unfortunately, this is not the case for several reasons.

Compilers and linkers use some well defined environmental variables to serve or get information on libraries. Typical examples are PATH, LD_RUNPATH, LD_LIBRARY_PATH, LIBRARY_PATH or PKG_CONFIG_PATH. If those may be usefull, they are set or modified, if a module is loaded. To see, which environmental variables are defined, use

       module show <package>/<version>

However, for building complex software, build-tools like autotools or cmake are used, which come with own rules, how information on to be linked libraries has to be delivered. In turn, the netcdf library uses nc-config and nf-config to deliver the information on the path to the netcdf headers and libraries. All serious build tools use this option and a netcdf-module just needs to deliver the path (PATH) to these tools. Very specific is cmake that searches for libraries instead of requesting information in a well defined way. This does not fit well in the philosophy of environment modules. Hence, there may be cases, where only the documentation on the to be build software helps.

Another issue may be that successfully linked libraries are not found when running the executable. One may be tempted to load the related module again. However, in most cases this does not help to overcome the problem, many modules do not have any effect during runtime. Here the solution is to avoid overlinking and to burn the path to the libraries into the executable. Read more on linking hdf5 and netcdf libraries with the help of the related environment modules.