Environment Modules at DIPC¶

At the heart of the Donostia International Physics Center's (DIPC) advanced computing infrastructure is the Lmod utility, a system designed to manage software applications, libraries, and compilers across it systems. This guide will walk you through the essential commands, insights, and best practices to help you navigate and optimize your usage of environment modules at DIPC.

Environment modules, managed by Lmod at DIPC, are a powerful tool for managing the computational environment on a UNIX-like operating system. They allow you to dynamically manage environment variables within the same shell session, enabling seamless switching of compilers, applications, path definitions, and more. This flexibility allows you to tailor your environment to your specific computational needs.

Module Commands¶

module help¶

Need a quick refresher on module options? Simply use the module help command:

$ module help

For guidance on a specific module, add the module name after module help:

$ module help modulefile

module avail¶

To list all the modulefiles available for loading, the module avail command comes in handy:

$ module avail

Many modulefiles have version numbers and, where multiple versions exist, one is typically designated as the default. To view hidden modulefiles, use the --show-hidden option:

$ module --show-hidden avail

module spider¶

The module spider command helps you understand the dependencies of different modules:

$ module spider FFTW

To extend the search to hidden modulefiles, use the --show-hidden option:

$ module --show-hidden spider libGLU

module display¶

To see what a specific modulefile does to your environment, use module display:

$ module display netCDF/4.4.1-intel-2016b

module load¶

The module load command adds one or more modulefiles to your current environment:

$ module load netCDF/4.4.1-intel-2016b FFTW/3.3.6-intel-2016b

module list¶

To list all loaded modulefiles, use module list:

$ module list

module unload¶

The module unload command removes a modulefile from the environment:

$ module unload intel/2022a

module purge¶

To remove all loaded modulefiles, use module purge:

$ module purge

Example: Load, Execute, and Unload a Module¶

Let's look at a typical scenario where you load a module, execute your program, and then unload the module once you're done. For this example, we'll be using the QuantumESPRESSO software package.

# Load the necessary module
$ module load QuantumESPRESSO/6.8-intel-2020a

# Check the modules currently loaded
$ module list

# Execute your QuantumESPRESSO program, for instance, pw.x
$ pw.x < pw.in > pw.out

# Once you're done, unload the module
$ module unload QuantumESPRESSO/6.8-intel-2020a

In the above steps, we first load the required module 'QuantumESPRESSO'. We then confirm that the module is loaded using the module list command. After executing our QuantumESPRESSO program (in this case, pw.x), we no longer need 'QuantumESPRESSO' loaded, so we unload it.

This example should give you a practical understanding of how to use the module commands in your daily work. Remember, the key is to ensure that you only load the modules you need at a given time and unload them once you're done to maintain a clean environment.

Understanding the Impact of Loading a Module on the Environment¶

When you load a module, it modifies your shell environment to set up the software package it represents. Let's examine some of the environment variables that can be affected, using the module display command.

$ module display QuantumESPRESSO/6.8-intel-2020a
help([[
Description
===========
Quantum ESPRESSO  is an integrated suite of computer codes
for electronic-structure calculations and materials modeling at the nanoscale.
It is based on density-functional theory, plane waves, and pseudopotentials
(both norm-conserving and ultrasoft).


More information
================
 - Homepage: https://www.quantum-espresso.org
]])
whatis("Description: Quantum ESPRESSO  is an integrated suite of computer codes
for electronic-structure calculations and materials modeling at the nanoscale.
It is based on density-functional theory, plane waves, and pseudopotentials
(both norm-conserving and ultrasoft).
")
whatis("Homepage: https://www.quantum-espresso.org")
whatis("URL: https://www.quantum-espresso.org")
conflict("QuantumESPRESSO")
load("intel/2021a")
load("HDF5/1.10.7-iimpi-2021a")
load("ELPA/2021.05.001-intel-2021a")
load("libxc/5.1.5-intel-compilers-2021.2.0")
prepend_path("PATH","/scicomp/EasyBuild/CentOS/7.4.1708/Skylake/software/QuantumESPRESSO/6.8-intel-2021a/bin")

PATH¶

The PATH environment variable is a list of directories that your shell searches when trying to execute a command. When you load a module, it often adds the paths to the software's executables to your PATH. This action allows you to call these executables from anywhere without having to specify their full paths.

For instance, loading the QuantumESPRESSO module adds the path to its executables (like pw.x) to your PATH, enabling you to simply type pw.x instead of its full path.

LD_LIBRARY_PATH¶

The LD_LIBRARY_PATH environment variable is a list of directories that the linker searches when trying to find shared libraries. When you load a module, it may add the paths to the software's libraries to your LD_LIBRARY_PATH. This action allows the linker to find these libraries when executing a program.

For example, loading the QuantumESPRESSO module ensures that the system knows where to find the QuantumESPRESSO shared libraries when you run a QuantumESPRESSO executable.

Other Environment Variables¶

Modules can also set other environment variables that are specific to the software package. For instance, a module could set variables that point to the software's data files or specify options for the software.

In the case of QuantumESPRESSO, there might be environment variables that point to pseudopotential files or that set options for running QuantumESPRESSO executables.

Unloading a Module¶

When you unload a module, it reverses the changes it made to your environment. This action often involves removing the paths it added from the PATH and LD_LIBRARY_PATH variables and unsetting any environment variables it set.

Maintaining a clean environment by unloading modules when they are no longer needed helps prevent potential conflicts between different software packages and helps ensure that your environment is set up correctly when you load a new module.

Understanding the Modulefile Naming Scheme¶

Modulefiles at DIPC follow a standardized naming convention: name/version-toolchain-toolchain-version. This naming scheme offers a comprehensive overview of the software's version and the toolchain used to build it. The toolchain version also provides the software's compatibility with other libraries and dependencies. This enables users to match software with the correct dependencies, ensuring smooth operation.

Importance of Toolchains and Their Usage¶

Toolchains are a critical part of software development and deployment on HPC systems. They represent a set of programming tools, including compilers and libraries, that work together to build applications. Consistency is key in the software building process, and toolchains ensure that the same set of tools is used each time software is built, thus improving reliability and preventing hard-to-debug errors caused by slight variations in tool versions.

Here are a few examples of toolchains and what they're used for:

GCCcore: This is the base of all toolchains, containing only the GCC compiler and its dependencies. It's used to build basic software that doesn't require specific libraries or dependencies.
foss: The 'foss' toolchain stands for 'Free and Open-Source Software'. It comprises the GCC compiler, Open MPI for parallelism, and BLAS, LAPACK, and ScaLAPACK libraries for numerical computations.
intel: This toolchain uses the Intel compilers and libraries. It's a commercial toolchain that often delivers better performance and efficiency on Intel hardware.
gompi: 'gompi' stands for 'GNU, Open MPI'. This toolchain is a combination of the GCC compiler and Open MPI library. It's commonly used in applications that require parallel computing.
fosscuda: This is similar to the foss toolchain but also includes CUDA, making it suitable for applications that can utilize GPU acceleration.

Remember that the choice of toolchain can significantly impact your application's performance. Therefore, you should consider the specifics of your application and the available hardware when selecting the toolchain.

Hidden Modules: An Insight¶

By default, some modulefiles are hidden from the standard module avail or module spider command. This approach is often employed to keep the list of available modules concise and to avoid potential confusion with deprecated or less frequently used modules.

However, these hidden modules can contain valuable tools or software versions. Therefore, if a specific software seems absent, you may want to check the hidden modules using the --show-hidden option. For instance:

$ module --show-hidden avail

Hidden modules are treated the same as regular modules once loaded into your environment. They can provide essential functionality that may not be available in the visible modules.

Customizing Module Behavior¶

The behavior of the module system is highly customizable, allowing you to tailor it to your specific needs. A key feature of this customizability is the ability to set the MODULEPATH environment variable, which determines the directories that the module command will search for modulefiles.

By default, the MODULEPATH is set to a system directory, which includes modulefiles for all the software installed on the system. However, you may wish to add your personal module directories to the MODULEPATH. This can be useful if you have installed your software or if you want to maintain a separate environment for a specific project.

To add a directory to the MODULEPATH, use the following command:

$ module use /path/to/your/modulefiles

Now, when you use module avail, it will also list the modulefiles located in /path/to/your/modulefiles.

It's important to note that this change is not permanent and will be reset when you start a new shell session. To make it permanent, you need to add the command to your shell's startup file (e.g., .bashrc or .bash_profile for the Bash shell).

Additionally, you can unload all currently loaded modules and reset your MODULEPATH to its default value with the module purge command. To then reload your custom MODULEPATH, use the module use command again.

In this way, you can customize your module environment to fit your needs, making the module system a flexible and powerful tool for managing your software environment on DIPC's HPC systems.