Multiple-Version Software and Modules Usage
BC Project: FY05-01
Date of Policy: 01 Oct 2006
Last Updated: 30 Sep 2021 (see Revision Log)
A minimum of three versions of all third party and open source software packages are required on the user-accessible systems (allocated HPC systems) at all participating HPCMP centers. These are:
- Production version
- Previous production version for validation and verification purposes
- Beta/Latest version to be made available as soon as it is released
Additional versions of a software package beyond the three required versions may be made available by a center when deemed necessary to meet center or user requirements. It is also recognized that on a new system or when a software package is first introduced on a system, fewer than the three required software versions may be initially available. In these exceptional cases a center is still considered compliant to this policy.
Participating centers will periodically review the third party and open source software directories on their systems to determine which packages, if any, have more than three versions available. If it is determined that one or more of the oldest versions are eligible for deletion by the center, a notice must be sent out by the center’s customer support team informing all users of the system that, unless otherwise requested by a user, the oldest version(s) of the installed software will be removed from the system after 30 days from the day of the notice. If no requests to maintain the oldest version(s) are received from any user before the end of the 30-day waiting period, access to the designated version(s) of the software and module(s) are eligible for termination on that system.
Also, on occasion, an operating system (OS) upgrade may cause certain older software packages and codes to no longer function correctly. When obsolete software is removed during an upgrade, the general OS upgrade announcements and notifications must also include all modules that are being removed.
In addition, all participating centers are required to install and use the Modules package to support multiple versions of compilers, associated libraries, and shared application packages. Compliance is determined by participating centers ensuring that the modules command is in the user's path and that system modulefiles are in place for the shared applications supported.
For information on standard module naming convention and directory structure, please see BC policy FY11-04 (Common Modules Environment).
For information on an improved modules-related command, called “bcmodule,” please see FY10-06 (Common DSRC Commands and Tools). The bcmodule command makes compiler and MPI modulefile names more consistent, finds modules, tracks down strings in modulefiles, and makes output easier to read. The bcmodule adds new features to the module command but does not replace it.
In cases where the modulefiles for applications depend on other modulefiles (an application may require compiler and library modulefiles to be loaded), or a conflict exists with a currently loaded modulefile (some modulefiles cannot coexist with other modulefiles), these dependencies and/or conflicts must be checked. A reasonable default modulefile may be loaded if the dependency is not met. A modulefile may by unloaded if a conflict exists, or a message may be displayed to the user indicating the dependencies and/or conflicts. In the event that loading a modulefile changes the module environment (by loading, unloading, or swapping modulefiles), the modulefile making these changes MUST inform the user of all changes via a terminal notification (a simple echo will generally accomplish this).
| Date | Revision |
|---|---|
| 30 Sep 2021 | BC Team Audit |
| 19 Feb 2019 | BC Team Audit – Removed reference to Utility Servers, since those systems have been decommissioned |
| 15 Mar 2018 | BC Team Audit – Added information about bcmodule |
| 05 May 2016 | BC Team Audit |
| 02 Apr 2015 | dded part of "determining whether oldest version of software is eligible for deletion" |
| 08 Apr 2014 | BC Team Audit - Combined with BC policy FY06-17 (Use of Modules for Accessing Multiple Versions of Software |
| 16 Mar 2012 | BC Team Audit |