Environment Modules for HPE CPE Supercomputing Systems
Overview
This documentation describes environment modules supported by CPE for users of module packages. CPE supports either Lmod or Environment Modules —- use the module command to manage user shell environments.
The following information assumes the reader has some familiarity with modules and CPE. (If you are a beginner, consulting Lmod and Environment Modules documentation is highly recommended.)
This document covers:
How environment modules work in the CPE environment
Differences between Lmod and Environment Modules
How to setup Lmod and Environment Modules
How to switch programing environments
How to create a custom module hierarchy (Lmod only)
This document does not cover the basic knowledge of what environment modules are or how to run specific CPE programs using environment modules.
Terms
The below terms shall be used throughout this document as defined below. These definitions are necessary, given the ubiquitous nature of the term “module” and the original module program called “Environment Modules.”
- modulefile
A file containing directives used to configure a user shell session for a specific product (for example, cray-mpich). Modulefiles typically set environment variables for command priority resolution, such as PATH and MANPATH.
- module tool
From the Environment Modules documentation: “The Modules package is a tool that simplifies shell initialization and lets users easily modify their environment during a session using modulefiles.” The user can “load” and “unload” packages into the running shell session via module commands. CPE provides two sets of modulefiles
Tcl modulefiles that can be used by Environment Modules 3.2 (PrgEnv-* modules are incompatible with Environment Modules 4.2+) or Lmod
Lua moduelfiles that can be used by Lmod (8+)
- Lmod
A module tool that enforces hierarchical dependencies and uses modules written in Lua. Lmod can interpret simple Tcl modulefiles as well.
- Environment Modules
(Formerly, Modules) A system for managing user shell environments by loading and unloading modulefiles that modify environment variables (for example, PATH and MANPATH). It enables dynamic selection of software versions and provides commands, such as module load, unload, and swap to control available tools. In CPE, Environment Modules is a fork from the original open source C code base of Modules.
- modules
This term may refer to either Lmod modules or Environment Modules.
- module
An Environment Module or Lmod modulefile.
Other Module Resources
CPE Documentation
CPE Installation Guide
CPE User Guide
CPE Release Announcements
External Resources
Modules Design Overview
How modules are designed to function within the CPE environment
System setup decisions:
Set up the CPE system with either Lmod or Environment Modules, as default.
Use the configuration files to set the default modules desired upon user login.
Set the default versions to be used on a system.
(Lmod only) Join customer Lmod hierarchies with the CPE Lmod hierarchy to make both directory trees act as one hierarchy on a system for all users.
Note: For more details see Setup System Modules
CPE package input requirements for environment module programs:
Each CPE package is required to support Lmod and Environment Modules. This is accomplished by the product package containing a Lua and Tcl modulefile. Each modulefile contains environment settings information specific to the CPE product it represents. (i.e. Adding a program path to “PATH” or setting a new environment variable to act as a program flag.)
Each CPE package must install both Environment Modules and Lmod modulefiles in specific module path locations. Lmod modulefile location is more complex since Lmod’s hierarchy features require a “nested” directory tree to function.
Each CPE package is also required to support “Set Default” which manages the different versions of CPE products and their modulefiles.
Note: The above settings are configured by a system administrator. For system specific details, please see HPE CPE Supercomputing Install Guide for your system.
UX/CrayPE Driver functionality inside module environments:
The driver provides an abstraction to compiler frontends, maintaining a common interface across vendors. The user can select targets (CPUs and offload GPUs) via the same modules, regardless of vendor/programming environment. The user is not required to write builds supporting flags for multiple compilers, as the driver will fill them in appropriately.
The driver provides delayed evaluation of CPE variables, reducing module complexity. For example: compilers and MPI libraries may be affected by the presence or selection of accelerator (GPU) targets. Rather than force a module to reload to change behavior, CPE “volatile” variables are offered that will not be evaluated until “driver” time (calling the compiler front-end for compile/link operations).
To see an example of the command-line generated by the CrayPE Driver run:
cc CC ftn <filename> -craype_verbose
Lmod vs Environment Modules
Lmod is based on Environment Modules (formerly, Modules). Lmod provides many of the same features as Environment Modules to dynamically modify a user environment. Key differences between Lmod and Environment Modules include:
Compiled tool:
Environment Modules was originally written in C requiring the executable modulecmd to be compiled
Lmod is implemented in Lua with an interpretor to read Tcl modulefiles
Conflict handling:
Environment Modules provides a conflict mechanism to express incompatibility between modules. Conflicts prevent modules from loading.
Lmod supports conflicts and adds a class designation
familyto express incompatibility with a single name rather than enumerating all other modules in class.
Hierarchical module environments:
Lmod uses the filesystem layout to express dependencies. It can block loading conflicting modules and restrict available modules configured through “hierarchy”.
Cache:
Lmod maintains caches of module availability to save time over a session using many operations.
Autoswapping:
Lmod will perform chained load/unload actions based on hierarchy with simple load/unload commands.
Note: Please note one level Lmod auto swapped modules are easily handled. For more complex multi-level auto swapped modules (such as swapping full programming environments) it is better to use the command
swap.This is due to the load order difference between amodule loadauto-swap and amodule swapwith multilevel dependancies being changed out.