Lmod modules — introduction and instructions

TIP: For the most robust listing of modules, please use the module search on our Portal https://portal.rc.fas.harvard.edu/apps/modules
or the module-query [name or partial name] command. These methods will yield much better results than commands like module spider or module avail.

About Modules

On the Odyssey cluster, we want a variety of apps available, including different versions of the same app and apps that are incompatible. We accomplish this by using environment modules. When you first login to the cluster, you're presented with a very basic software environment. You then make apps available to you or your jobs by loading the modules for them. The modules update shell environment variables so that the system can find and use the apps of your choice. Modules replace the need for separate setup scripts.

Our implementation of environment modules uses Lmod and the bash shell. That page has some excellent documentation for those wishing to learn more about 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. Below is a condensed version with more FASRC-specific information.

We often refer to this as the new, lmod module system, although it has been in used since 2014. The legacy module system is almost entirely deprecated and will be completely retired in 2018 with the Odyssey3 rollout.

How to Use Modules

The Lmod module system requires the following command:

source new-modules.sh

Note: If your account was created in late 2015 or beyond, this command is already in your .bashrc - If your .bashrc does not contain this line, you should add it so that you do not need to invoke it manually. Otherwise, you would need to include it in job scripts and invoke it at each login before loading modules.

You can now load one or more modules using the module load [module(s) name] command. Examples:

module load matlab/R2016b-fasrc01

module load gcc/6.3.0-fasrc01 openmpi/2.0.2-fasrc01 abyss/2.0.2-fasrc01

To see what modules you have loaded, run:

module list

To unload a module, run:

module unload [module name]

To unload all modules currently loaded, run:

module purge

Finding Modules

For the most robust listing of modules, please use:

You may also see mention of module spider, however the methods above will yield much better results.

If you find there are modules you need that are not available, you may either install the software for yourself, or let us know if there is software that you believe will benefit many users by submitting a software install ticket.

Loading a Module May Reveal More Modules

For example, loading intel/17.0.4-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 Initial list using the module avail command After loading module intel, applications built with the intel compiler are made available and become the default After loading this module, applications built with the intel compiler are made available and become the default

Bear in mind that the module avail command does not show all the different modules you could possibly use. You should use module-query or the portal to find specific modules. module avail is used here to demonstrate how you can see the change in available modules when loading modules that unlock a dependency and make other modules available. 

Module Naming and Versioning

You can load specific versions by supplying the full module name (example: module load matlab/R2017a-fasrc01) or let the module system automatically load the latest version (example: module load matlab). The default is determined either according to alphanumeric sorting or in some cases the version we have chosen to be the default latest version based on stability or commonality. It is not recommended to load modules in this fashion but rather modules should be loaded by name and specific version.  This way you are protected in case the default version changes.

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. This has the potential to cause issues if a specific version is required. Be sure to look at the module's requirements before assuming this will work. Or, at the very least, test your script before trusting that it will work.

Additional Notes

If you've used Odyssey 1 or Odyssey 2 in the past, you may recall modules producing a confirmation output when loaded. Loading modules no longer prints any output to the screen to avoid issues in non-interactive or other sessions which are not expecting output.

TIP: If you do have your .bashrc or other at-login script print or echo output to stdout (standard out - that is, displayed back to your shell session) by default, this is likely to cause issues if you attempt to SFTP to the cluster. Many SFTP clients will fail at login when something prints back to stdout after you've authenticated. Removing whatever prints to stdout from your script will resolve this problem.

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.