Lmod modules — introduction and instructions

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.

How to use it

The Lmod module system requires the following command:

source new-modules.sh

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.

Legacy Modules

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.

Initial list using the module avail command After loading module intel, applications built with the intel compiler are made available and become the default

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. module avail.

More systematic module naming and versioning

We have no more categorical prefixes on the module names -- modules are APP/VERSION rather than thing like math/APP-VERSION or 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.

CC BY-NC 4.0 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.