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).

Each system will have module directories as defined below:

• /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_direcotry/devel directory, and not the "compiler" and "mpi" sub-directories.
• /some_directory/COTS
  This is for COTS, GOTS, and FOS 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 and SLM), as well as general use software that does not fit the other categories

Compliance

Since many users already have modules incorporated into their scripts, it is important no changes are made to existing systems that will potentially break scripts.

For TI-11 and earlier systems, a system is consider complaint with the naming conventions if all software controlled by modules follows the defined naming conventions. For backward compatibility, it is acceptable to continue to provide existing module files with names outside this naming convention. For TI-12 and later systems, a system will be considered non-compliant if there are module files that do not follow this naming convention.

Since module directories are embedded in $MODULEPATH, changing the directories where module files are located should not break any existing scripts. However, with the new requirement for compiler and MPI module files to be in separate directories, it is possible moving these module files will break some scripts. Therefore, for TI-11 and earlier systems, a system is consider compliant with the directory structure if all the defined directories are provided and the module files are properly located. There may be redundant modulefiles in /some_directory/devel for the compiler and MPI modules for backward compatibility. For TI-12 and later systems, a system is considered non-compliant if there are module files that are located in directories not specified by this policy.