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:

  1. Defining a standard naming convention for module files.
  2. 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.


Revision Log
Date Revision
08 Dec 2020Replaced PBS scheduler by a generic HPC job scheduler
31 May 2018BCT Team Audit
20 Oct 2017Command "bcmodule" introduced in the policy
09 Jun 2016BC Team Audit
08 May 2014BC Team Audit - Module directory ending with "COTS" replaced by "apps"