...

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:

...

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 HLRN 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 HLRN support 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 at HLRN.

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

...

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. At HLRN the The modules are sorted into CATEGORIES (all capital letters).

...

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

The modified environmental variables can be used by compilers, linkers, make, cmake or private software installation tools, to recognise details of installed libraries and link them accordinglyMany 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, how a package is installed and which environmental variables are delivereddefined, 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.