Stable release |
3.2.10 / December 21, 2012
|
---|---|
Operating system | Unix-like |
License | GNU General Public License#Version 2 |
Website | modules |
The Environment Modules system is a tool to help users manage their Unix or Linux shell environment, by allowing groups of related environment-variable settings to be made or removed dynamically.
Modules has been around since the early 1990s and is used at some of the largest computer centers to deploy multiple versions of different software tools to users. The National Energy Research Scientific Computing Center (NERSC) reports that they use Environment Modules to manage nearly all software. Environment Modules is specified as a Baseline Configuration requirement of the DoD High Performance Computing Modernization Program (HPCMP) Project Baseline Configuration team for participating DoD Supercomputing Resource Centers (DSRCs).
The modules system is based on modulefiles, which specify groups of environment settings that need to be made together. Modulefiles can be installed in a central location for general use, or in a user directory for personal use. Environment Modules modulefiles are written in the Tcl (Tool Command Language) and are interpreted by the modulecmd program via the module user interface.
The key advantage of Environment Modules is that it is shell independent and supports all major shells such as bash, ksh, zsh, sh, tcsh, and csh. The second key advantage is that it allows to use multiple versions of the program or package from the same account by just loading proper module. Those two advantages were instrumental in making Environment Modules a part of most HPC cluster setups. It also inspired several alternative implementation such as lmod from University of Texas, which is written in Lua instead of TCL.
modulefiles are created on per application per version basis. They can be dynamically loaded, unloaded, or switched. Along with the capability of using multiple versions of the same software it also can be used to implement site policies regarding the access and use of applications.
The default modules search path is in a hidden configuration file you can display with:
The /etc/modulefiles directory used by some distributions (or any other directory) can be used after a build from source by modifying the ${MODULESHOME}/init/.modulespath file.
The ${MODULESHOME}/modulefiles/use.own module essentially performs these steps.
The commands in this section require read/write/execute access to the /etc/modulefiles directory. The $HOME/privatemodules or another directory can be used instead along with "module use --append" or modification of the configuration file specifying the default modules search path.
The default modulefiles directory is empty initially. Copy the null module to the default modulefiles directory to have it shown by "module avail". The following uses the null and module-info modules to show use of a version file within a hierarchical organization and their effect on module avail and module show: