Bright:Modules Enviroment

Modules Environment

A module is a file used to set up the Paths in linux to allow the use of some software. The Modules Environment is a third party piece of software that allows users to modify their shell environment using pre-defined modules.

Listing, Adding or Removing a Module

List modules with these 2 commands:

module list #List the currently loaded modules

module avail #List the available modules of loading

Add modules with these 2 commands:

module load <module name 1> <module name 2>

module add <module name 1> <module name 2>

Remove modules with these 3 commands:

module unload <module name 1> <module name 2>

module rm <module name 1> <module name 2>

module purge #Remove all the loaded modules

As an example this would load the gcc, openmpi and openblas modules, compile a code and then remove the modules:

module add shared
module add gcc
module add openmpi/gcc
module add openblas/nehalem

mpicc -o myapp myapp.c

module rm gcc openmpi/gcc openblas/nehalem

Using Local or Shared Modules

Applications and their associated modules are divided into local and shared groups. Local applications are installed on the local file-system, whereas shared applications reside on a shared (i.e. imported) filesystem. The shared module is loaded by default for ordinary users. Loading it gives access to the modules belonging to shared applications, and allows the module avail command to show these extra modules.

Loading the shared module automatically for root is not recommended on a cluster where shared storage is not on the head node itself, because root logins could be obstructed if this storage is unavailable. The shared module is therefore not loaded by default for root.

On clusters without external shared storage, root can safely load the shared module automatically at login. This can be done by running the following command as root:

module initadd shared

Default environment

The initial state of modules in the user environment can be set as a default using the module init* subcommands.

module initadd <module name> #Automatically load the desired modules, on boot

module initrm <module name> #Remove a module from the initial state

module initlist #List all modules loaded initially

module initclear #Clear all modules from the default initial state

On the other hand, the administrator can configure the default environment of all users by two ways:

1. Appending module load commands in the /etc/profile.d/userdefaultmodules.sh file,
2. Setting the desired modules to be loaded in the default-environment modulefile (located in /cm/shared/modulefiles/) and then load the default-environment module in the userdefaultmodules.sh file.

Creating a New Module

All module files are located in the /cm/local/modulefiles and /cm/shared/modulefiles trees. A module file is a TCL script in which special commands are used to define functionality. The modulefile(1) man page has more on this.

Cluster administrators can use the existing modules files as a guide to creating and installing their own modules for module environments, and can copy and modify a file for their own software if there is no environment provided for it already by Bright Cluster Manager.

To create a new module:

cd /cm/shared/modulefiles  # go to the modulefiles directory

mkdir new-module  # create a new folder that will contain the module. Folders help keeping modules organised

vim module-name-version  # create the actual module

For example, the following code sample creates and loads a new module, which enables the GCC compiler:

cd /cm/shared/modulefiles
mkdir gcc
vim 4.8.2
module load gcc/4.8.2

Tha actual gcc/4.8.2 module would be the following:

#%Module -*- tcl -*-
##
## modulefile
##
proc ModulesHelp { } {

  puts stderr "\tAdds GNU Cross Compilers to your environment variables,"
}

module-whatis "adds GNU Cross Compilers to your environment variables"

set               root              /cm/shared/apps/gcc/4.8.2
prepend-path      PATH              $root/bin
prepend-path      LD_LIBRARY_PATH   $root/lib:$root/lib64

Meta Modules

Modules can be combined in meta-modules. By default, the default-environment meta-module exists, which allows the loading of several modules at once by a user. Cluster administrators are encouraged to customize the default-environment meta-module to set up a recommended environment for their users. The default-environment meta-module is empty by default.

The administrator and users have the flexibility of deciding the modules that should be loaded in undecided cases via module dependencies. Dependencies can be defined using the prereq and conflict commands.

• The prereq command lists modulefiles which must have been previously loaded before the current modulefile will be loaded. If an argument for prereq is a directory and any modulefile from the directory has been loaded, then the prerequisite is met.
• Similarly, the conflict command lists modulefiles which conflict with the current modulefile. If an argument for conflict is a directory and any other modulefile from that directory has been loaded, then a conflict will occur.

The man page for modulefile gives details on configuring the loading of modules with these commands.