Common Modules Environment
BC Project: FY11-04
Date of Policy: 16 Mar 2012
Last Updated: 08 Dec 2020 (see Revision Log)
The use of modules software has become part of the standard workflow for many users. Many users have incorporated modules calls into their HPC job scheduler. Unfortunately, the use of different module file 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 module files when the
module files for a particular application are found in different directories from one
system to another.
To address these two issues the BCT provides bcmodule, which also has a number
of other features. 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 modules in general, and using
bcmodule in particular.
There are some system specific module files 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 module files.
- Defining a standard directory structure for module files.
Defining a standard naming convention
Most applications have some version number associated with them. This policy defines the standard
naming convention for module files as application/version. As an example, for some application named
foobar, the module file for version 1.2.3 of this software will be located 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 located in similar directories across systems. This portion
of the policy defines where the module files 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 |
|---|---|
| 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" |