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:

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


Revision Log
Date Revision
09 Dec 2021BC Team Audit
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"