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, if /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:

/some_directory/devel

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/compiler and /some_directory/devel/mpi. However, for consistency, the $MODULEPATH environment variable should only include the /some_directory/devel directory, and not the compiler and mpi sub-directories.

/some_directory/apps

This is for COTS, GOTS, and FOSS software. This includes applications and libraries.

/some_directory/unsupported

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.

/some_directory/modulefiles

This is for system required software (such as PBS), as well as general use software that does not fit the other categories.

Compliance

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 compiler and mpi subdirectories to be considered compliant.