Difference between revisions of "Bright:Modules Enviroment"

From Define Wiki
Jump to navigation Jump to search
Line 70: Line 70:
 
module initclear #Clear all modules from the default initial state:
 
module initclear #Clear all modules from the default initial state:
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
On the other hand, the administrator can configure the default environment of all users by two ways:
 +
 +
#Appending <tt>module load</tt> commands in the <tt>/etc/profile.d/userdefaultmodules.sh</tt> file,
 +
#Set the desired modules to be loaded in the <tt>default-environment</tt> modulefile (located in <tt>/cm/shared/modulefiles/</tt>) and then load the <tt>default-environment</tt> module in the <tt>userdefaultmodules.sh</tt> file.
  
 
=== Meta Modules ===
 
=== Meta Modules ===

Revision as of 17:40, 29 October 2014

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. Set 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.

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 metamodule 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 man page for modulefile gives details on configuring the loading of modules with these commands.

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.