Skip to content

Modules at CHPC

There is a short training video that covers the basics of modules. Modules is an environment management tool which makes modifying the user's shell environment simple and dynamic. The advantage of modules primarily comes from the capability to load and unload the environment needed for a given software package, allowing users to quickly and easily start using programs or switch development environments.

CHPC uses the Lmod version of modules produced by TACC. For more information, please visit the Lmod documentation page.

How to Use Modules

The use of modules is very well described in the User Guide for Lmod. In particular, please, go over the first section that describes how to list the active modules (module list or ml), load a module (module load XX or ml XX), unload a module (module unload XX or ml -XX) and search for a module (module spider XX or ml spider XX; or more widely module keyword XX or ml keyword XX - XX being a module name or a keyword).

An important note about module avail is that the command does not show all packages that exist on the system. The reader may notice there are no MPI modules listed; this is because the use of an MPI library depends on having a compiler loaded through the module hierarchy. To see a list of all  available modules, please use the command module spider.

To search for a specific module, specify a name:

$ module spider mvapich2
  To find detailed information about mvapich2 please enter the full name.
  For example:
     $ module spider mvapich2/2.2

Then execute spider with a version as well and receive instructions on how to load the module:

$ module spider mvapich2/2.2
  mvapich2: mvapich2/2.2
    This module can only be loaded through the following modules:
We periodically deprecate older versions of programs by hiding their modules. To also show the hidden modules, use the --show-hidden option in the module avail, spider, etc. commands. Hiding a module does not affect its loading capability, module load can be executed on a hidden module without the need for --show-hidden.

For more information on modules, see the Advanced Modules Guide.

Customizing CHPC modules

Users can customize the way how the modules are named and shown using the ~/.modulerc file.  The ~/.modulerc file syntax is as follows:

if { [info exists ::env(LMOD_VERSION_MAJOR)] } {
#Lmod stuff
hide-version idl/8.0
module-version python/2.7.11 2.7
module-alias python2 python/2.7.11

As can be seen in the example above, one can hide the display of the module in module avail command (which CHPC does by default on older program versions), and, more usefully for an user, create a custom version or alias to the module, which is especially useful to shorten long version names or create a custom name for a given version.

CHPC's global custom file, which is used to hide deprecated modules, shorten versions and set aliases to commonly used modules, is in /uufs/ .

Customizing the default user environment via .bashrc/.tcshrc

CHPC has streamlined its approach to customizing user environments. As mentioned before, CHPC strongly discourages the modification of .bashrc/.tcshrc files. This is because any time CHPC releases new versions of these files, often users will have their shell environment broken by the changes. CHPC has provided the and custom.csh files for users to customize their environment. The user should have copied these files already (or started with them in a new user account).  After copying, these files should work seamlessly with the .bashrc/.tcshrc. The user is free to make any modifications they want in the custom scripts. As a convenience, a means for modifying environments on a cluster specific basis is also given in the custom script.

Setting up command aliases

Users can create a .aliases file in their home directory to set up any command aliases that they want to have defined in their working environment. If this file exists, it will automatically be sourced upon login by the .tcshrc/.bashrc file.


Setting up Modules

CHPC has implemented modules on all of its clusters in 2015 to improve the user experience and to align with other national computing centers which are using modules. 

While the CHPC users have the choice to adopt the module environment or to remain with the script sourcing method that has been used in the past, most have switched to the use of environment modules.  All new users accounts are started with the module option.  We keep this modules setup section for those who still have not migrated but wish to do so.

In order to implement the modules existing CHPC users will have to replace their current script sourcing based .bashrc and .tcshrc files as outlined below. 

To enable modules, the user will need to copy the CHPC bashrc and tcshrc to their home directory:

cp /uufs/ ~/.bashrc
cp /uufs/ ~/.tcshrc

To set up the default CHPC environment, users will also need to copy the and custom.csh scripts

cp /uufs/ ~/
cp /uufs/ ~/.custom.csh

Existing CHPC users may want to make backup copies of their existing .tcshrc or .bashrc if they have particular modifications which they would like to preserve. After copying the .bashrc/.tcshrc, the user will need to log out and log in. After this, the user should be able to use modules. Users should not modify the .bashrc/.tcshrc; instead, place all custom shell environment in Users may create a ".aliases" file if they desire, which will be automatically sourced by the .bashrc/.tcshrc. CHPC strongly discourages users from setting environment variables in ".aliases"; the file should only contain alias commands.

Note: Bash users should ensure that the .bash_profile file is present in $HOME.

Last Updated: 7/5/23