The environment modules lifecycle
On Peregrine, “modules” are used to customize your runtime environment by loading and unloading modules that are needed to accomplish the task at hand. To keep the application environment manageable, we have several different collections of modules, each serving a different purpose. Each collection is in a different location in the /nopt file system:
/nopt/Modules/3.2.10/modulefiles : This collection is maintained in parallel to the application modules, and provides longer-term access to toolchains, key development tools (i.e., low-level libraries like MKL, debuggers and profilers), and system-level tools like nitro or robinhood.
/nopt/nrel/apps/modules/candidate/modulefiles : Modules undergoing testing. While these usually enable the latest versions of toolchains, middleware, and applications, they are subject to modification or deletion at any time.
/nopt/nrel/apps/modules/default/modulefiles : These are the modules “in production,” and are visible to all users by default. They should work correctly, but if you find one that doesn’t, e-mail firstname.lastname@example.org to let us know.
/nopt/nrel/apps/modules/deprecated/modulefiles : As versions advance, we periodically clean up the production collection to keep software selection relatively up-to-date. Older versions are moved to this collection to provide users a period of time to migrate their workflows to newer versions if needed.
/projects/$PROJECT/modules/default/modulefiles : It is not widely appreciated, but anyone can create a modules collection themselves. For a project where multiple members need to have access to a single environment, their /projects/$PROJECT directory can host a modules collection that can be freely administered by one or more project members.
/home/$USER/modules/default/modulefiles : Analogously to modules for a project, an individual $USER can keep their own collection of modules and administer them freely.
In order to see modulefiles in any location, you need only add that location to your MODULEPATH environment variable. That can be done easily via module use /path/to/collection (put this /path/to/collection at the head of MODULEPATH, so modules in this collection take loading priority over those with the same name in other collections)
module use -a /path/to/collection (append this /path/to/collection to the end of MODULEPATH, so modules with the same name in other collections take loading priority over modules in this collection)
For module collections that you want persistent access to, the above 2 commands can be put into your shell startup script (e.g., .bash_profile for BASH).