Default modules naming convention, directory structure, and compliance requirements
To enable the simple loading of default versions, centers will make use of the .version method
provided by the modules software to designate the default version. This will cause the default
version to be identified automatically through the
module avail command. If version
1.2.3 is the default version of foobar, but version 2.0.1 is also available, users can load the
default by simply entering
module load foobar. If a user wants to load the non-default
version, this is accomplished by specifying the version number
module load foobar/2.0.1).
We recognize the default version functionality is not working at a nested level at this time
(June 2016) and is beyond our control. Compliance will not be affected by this bug until a fix
is in place by the vendor. However, default versions must be supported at the first level. That is,
/ABC/XYZ is in the
$MODULEPATH, then module files in
/ABC/XYZ/foobar must utilize the default version feature, but module files in
/ABC/XYZ/tools/sometool are exempt until this bug is addressed.
Each system will have module directories as defined below, with these paths defined in the
$MODULEPATH environment variable:
- This is for development tools such as compliers, message passing libraries, I/O libraries,
and debuggers. To make it easier for users to know what module files are for compilers and
MPI libraries, there will be the additional directories
/some_directory/devel/mpi. However, for consistency, the
$MODULEPATHenvironment variable should only include the
/some_directory/devel directory, and not the
- This is for COTS, GOTS, and FOSS software. This includes applications and libraries.
- This is for software that is not officially supported by a center. This is NOT intended for users to create module files, but rather for center staff to provide module files for unsupported software. It is important that center staff ensure no module file names here conflict with those in the other directories.
- This is for system required software (such as PBS), as well as general use software that does not fit the other categories.
Since many users already have modules incorporated into their scripts and module directories
are embedded in
$MODULEPATH, changing the directories where module files are located
should not break most existing scripts. However, it is very important no changes are made to
existing systems that will potentially break scripts.
With the requirement for compiler and MPI module files to be in separate directories, it is
possible moving these module files will break some scripts. Therefore, a system commissioned
prior to the 2016 audit of this policy is considered compliant if all the defined directories
are provided and the module files are located within any of the specified directories in this
policy. Any system commissioned after this date must make use of the
mpi subdirectories to be considered compliant.