Table of Contents
In the Summer of 2014 we updated the way we handle software modules on the FAS RC Odyssey cluster. The new modules system is implemented with Lmod. In addition to some new features, we've adopted a more systematic naming and versioning convention, and we're more actively curating our app inventory.
The full documentation on the new lmod module system is here. We refer to this as the new, lmod module system, as compared to the old or legacy module system.
Looking for particular modules/software? Search Modules Here
How to use it
The Lmod module system requires the following command:
Note: If your account was created in late 2015 or in 2016, this command is already in your .bashrc giving you the new module system by default.
This will only affect your current shell session. To make the new Lmod system your default, add the above to your
~/.bashrc file. The csh-family shells are not supported, but will be when we make this the default for all logins.
If you find there are modules you need that are not available in the new system you may either install them yourself, or let us know. While we're working on adding them, you can run the following command to make available all the old modules:
module load legacy
After you run that, you can load what you're accustomed to loading from the legacy system.
If you want to write logic in your ~/.bashrc file and scripts that conditionally do things with modules depending on which system you're using, you can use the environment variable
$FASRC_MODULE_FLAVOR. Its value is
legacy under the old system and
lmod under the new system.
Loading a module may make more modules available
For example, loading
intel/13.0.079-fasrc01 will make available all the apps compiled with that version of the intel compiler suite. This is done for each compiler choice and for each MPI implementation choice.
This also means that
module avail does not show all the different modules you could possibly use. See the main documentation about
module spider vs.
More systematic module naming and versioning
We have no more categorical prefixes on the module names -- modules are
APP/VERSION rather than thing like
centos6/APP-VERSION. We also have no more version suffixes like
APP-latest that get stale and incorrect. Loading
APP, without any version specified, will automatically load the latest version (according to alphanumeric sorting or whatever we have chosen to be the default latest version). Also, since modules are arranged in a hierarchy based upon compiler and/or mpi version, those dependencies are not repeated in the module names.
Less aggressive module version changes when loading dependencies.
If module A requires module B, and you already have some version of B loaded, A will usually consider the dependency satisfied, rather than force a specific different (often older) version of B to be loaded, as it usually did in the legacy module system.
Less verbose output
Loading modules no longer prints any output to the screen.
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Permissions beyond the scope of this license may be available at Attribution.