Creating local module directory
You can use your own custom modules to setup your environment to run programs that you have installed yourself. This tutorial will guide you through creating a custom module directory, adding versioned modules for programs, and automatically having these modules available to you upon login. The tutorial will assume you will be managing a set of modules for a whole group, though it is equally applicable to managing a personal set of modules.
Please note that on Euler, we are using environment modules, whereas on Leonhard we are using LMOD modules. When extending the centrally provided modules, please make sure that you use the correct module type for your own modules.
Creating a custom module directory (environment modules)
You need to decide on the top-level directory (we will use the placeholder __TLD__ for the examples) in which to store the module files. You need to create the directory and set the user and group ownership:
[sfux@eu-login-01-ng ~]$ cd __TLD__ [sfux@eu-login-01-ng __TLD__]$ chown sfux:sfux-group modules
Here you would need to replace sfux and sfux-group with your account name and personal group (or any other IAM group that is suitable for this purpose).
==Creating a custome module directory (LMOD modules)
As described above, you would need to create a top level directory for your modules first. Then download the  file and untar it in your top level directory. This will provide the skeleton of directories for the module hierarchy:
[sfux@eu-login-12 my_modules]$ tar -xzvf local_modules.tar.gz Compiler/ Compiler/gcc/ Compiler/gcc/8.2.0/ Compiler/gcc/8.2.0/openmpi/ Compiler/gcc/8.2.0/openmpi/3.0.1.lua Compiler/gcc/8.2.0/openmpi/4.0.2.lua Compiler/gcc/4.8.5/ Compiler/gcc/4.8.5/openmpi/ Compiler/gcc/4.8.5/openmpi/3.0.1.lua Compiler/gcc/4.8.5/openmpi/4.0.2.lua Compiler/gcc/6.3.0/ Compiler/gcc/6.3.0/openmpi/ Compiler/gcc/6.3.0/openmpi/3.0.1.lua Compiler/gcc/6.3.0/openmpi/4.0.2.lua Compiler/intel/ Compiler/intel/18.0.1/ Compiler/intel/18.0.1/openmpi/ Compiler/intel/18.0.1/openmpi/3.0.1.lua Core/ Core/gcc/ Core/gcc/4.8.5.lua Core/gcc/8.2.0.lua Core/gcc/6.3.0.lua Core/intel/ Core/intel/2018.1.lua Core/intel/18.0.1.lua MPI/ MPI/openmpi/ MPI/openmpi/3.0.1/ MPI/openmpi/3.0.1/gcc/ MPI/openmpi/3.0.1/gcc/8.2.0/ MPI/openmpi/3.0.1/gcc/4.8.5/ MPI/openmpi/3.0.1/gcc/6.3.0/ MPI/openmpi/3.0.1/intel/ MPI/openmpi/3.0.1/intel/18.0.1/ MPI/openmpi/4.0.2/ MPI/openmpi/4.0.2/gcc/ MPI/openmpi/4.0.2/gcc/8.2.0/ MPI/openmpi/4.0.2/gcc/4.8.5/ MPI/openmpi/4.0.2/gcc/6.3.0/ MPI/openmpi/4.0.2/intel/ MPI/openmpi/4.0.2/intel/18.0.1/
Now you can start to add your self created modules into the hierarchy.
This is work in progress and not yet documented.
Using the custom module directory
Now you need to let the module command know about your custom directory. Add the following line to your $HOME/.bash_profile file in case you are the only person using the additional modules. Or you can create a script that can be sourced in case multiple people use the additional modules.
For the Euler cluster:
module use __TLD__/leonhard/modules
For the Leonhard cluster:
The module command will now see your custom modules the next time you log in. You can also type this command into your current shell to have immediate access.
Every group members will need to do this setup step to see the modules. Please note that on Leonhard, we are using a Setting_up_your_environment#Hierarchical_modules module hierarchy containing of 3 layers (Core, Compiler and MPI). Module stacks that extend the central module files will be handled by LMOD like an additional Core layer, i.e., modules will not be reloaded when the compiler or the MPI version are changed. In this regard, the module hierarchy will also not manage potential conflicts between extension modules and the existing hierarchy.
Example module files
For each software that you would like to create a module for, create a directory in the modules directory. This directory then contains the file whose name is the version number. In this example, we use PROGRAM as placeholder and 1.0 as version. The module file would therefore be stored in __TLD__/modules/PROGRAM and have the name 1.0
#%Module1.0 module-whatis "This is my software PROGRAM version 1.0" set helpmsg "PROGRAM is used used to achieve the following task ..." set topdir "__TLD__/apps/PROGRAM/1.0" setenv IMPORTANT_VARIABLE "Some string" prepend-path PATH $topdir/bin prepend-path LD_LIBRARY_PATH $topdir/lib64 prepend-path C_INCLUDE_PATH $topdir/include
For each software that you would like to create a module for, create a directory in the modules directory. This directory then contains the file whose name is the version number followed by the ending .lua. In this example, we use PROGRAM as placeholder and 1.0 as version. The module file would therefore be stored in __TLD__/modules/PROGRAM and have the name 1.0.lua
-- -*- lua -*- -- -- Any sort of comment can be put here -- -- whatis([[Name : This is my software PROGRAM version 1.0]]) help([[PROGRAM is used to achieve the following task ...]]) setenv("IMPORTANT_VARIABLE", "Some string") prepend_path("PATH", "__TLD__/apps/PROGRAM/1.0/bin") prepend_path("LD_LIBRARY_PATH", "__TLD__/apps/PROGRAM/1.0/lib64") prepend_path("C_INCLUDE_PATH", "__TLD__/apps/PROGRAM/1.0/include")