Common Modules Environment
BC Project: FY11-04
Date of Policy: 16 Mar 2012
Last Updated: 09 Dec 2021 (see Revision Log)
The Environmental Modules software has become part of the standard workflow for many users. Many users have incorporated module calls into their HPC job submission scripts. Unfortunately, the use of different modulefile naming conventions between sites, between systems, and even within systems, can make it difficult to port these scripts from one system to another. A complicating factor is the use of different modules directory structures between systems.
Furthermore, as more applications make use of modules to control application access, the
output of a module avail command is becoming longer and more difficult to
navigate. This makes it difficult for users to locate the correct modulefiles when the
modulefiles for a particular application are found in different directories from one
system to another.
To address these two issues and provide additional features, the BCT provides
bcmodule. The tool bcmodule is a wrapper for the native
module command.
This tool has been incorporated into BC Policy FY10-06
(Common DSRC Commands and Tools) which specifies its availability on all HPC systems.
Please refer to FY10-06 for documentation on the use of module and
bcmodule.
There are some system-specific modulefiles provided by the vendor. These should not be changed. This policy does not apply to system-specific modules, such as the Cray modules.
This policy consists of two components:
- Defining a standard naming convention for modulefiles.
- Defining a standard directory structure for modulefiles.
Defining a standard naming convention
Most applications have some version number associated with them. This policy defines the standard
naming convention for modulefiles as application/version. As an example, for some application named
foobar, the module file for version 1.2.3 of this software will be in a
directory foobar, and be named 1.2.3. This allows a user to load this version
of the software with module load foobar/1.2.3.
Defining a standard directory structure for module files
It is important that similar software be in similar directories across systems. This portion
of the policy defines where the modulefiles for different types of software should be located. For
the purpose of this policy, some_directory is generic and can be different across sites,
across systems, and even within a system. The name of the leaf directory is what must be consistent.
Each system will have module directories as defined below:
/some_directory/devel/some_directory/apps/some_directory/unsupported/some_directory/modulefiles
For more details, including compliance criteria, click on additional information.
| Date | Revision |
|---|---|
| 09 Dec 2021 | BC Team Audit |
| 08 Dec 2020 | Replaced PBS scheduler by a generic HPC job scheduler |
| 31 May 2018 | BCT Team Audit |
| 20 Oct 2017 | Command "bcmodule" introduced in the policy |
| 09 Jun 2016 | BC Team Audit |
| 08 May 2014 | BC Team Audit - Module directory ending with "COTS" replaced by "apps" |