Usage of Environment Modules

savemodules will save your currently loaded set of modules for all future logins.

unsavemodules will clear the saved modules so that they will not load on next login.

module [switches] [sub-command] [sub-command-args]

module is a user interface to the Modules package. The Modules package provides for the dynamic modification of the user's environment via modulefiles.

Each modulefile contains the information needed to configure the shell for an application. Once the Modules package is initialized, the environment can be modified on a per-module basis using the module command which interprets modulefiles. Typically modulefiles instruct the module command to alter or set shell environment variables such as PATH, MANPATH, etc. modulefiles may be shared by many users on a system and users may have their own collection to supplement or replace the shared modulefiles.

The modulefiles are added to and removed from the current environment by the user. The environment changes contained in a modulefile can be summarized through the module command as well. If no arguments are given, a summary of the module usage and sub-commands are shown.

The action for the module command to take is described by the sub-command and its associated arguments.  

Command line switches

The module command accepts command line switches as its first parameter. These may be used to control output format of all information displayed and the module behavior in case of locating and interpreting module files.

All switches may be entered either in short or long notation. The following switches are accepted:

--help, -H

Give some helpful usage information, and terminates the command.

--version, -V

Lists the current version of the module command, and some configured option values. The command then terminates without further processing.

--force, -f

Force active dependency resolution. This will result in modules found on a prereq command inside a module file being load automatically. Unloading module files using this switch will result in all required modules which have been loaded automatically using the -fswitch being unload. This switch is experimental at the moment.

--terse, -t

Display avail and listoutput in short format.

--long, -l

Display avail and listoutput in long format.

--human, -h

Display short output of the avail and listcommands in human readable format.

--verbose, -v

Enable verbose messages during module command execution.

--silent, -s

Disable verbose messages. Redirect stderr to /dev/null if stderr is found not to be a tty. This is a useful option for module commands being written into .cshrc, .login or .profile files, because some remote shells (as rsh(1)) and remote execution commands (like rdist) get confused if there is output on stderr.

--create, -c

Create caches for module avail and module apropos. You must be granted write access to the ${MODULEHOME}/modulefiles/ directory if you try to invoke module with the -coption.

--icase, -i

Case insensitive module parameter evaluation. Currently only implemented for the module aproposcommand.

--userlvl <lvl>, -u <lvl>

Set the user level to the specified value. The argument of this option may be one of:

novice, nov Novice

expert, exp Experienced module user

advanced, adv Advanced module user  

Module Sub-Commands

help   [modulefile...]

Print the usage of each sub-command. If an argument is given, print the Module-specific help information for the modulefile(s).

add    modulefile...

load   modulefile...

Load modulefile(s) into the shell environment.

rm     modulefile...

unload modulefile...

Remove modulefile(s) from the shell environment.

swap   [modulefile1] modulefile2

switch [modulefile1] modulefile2

Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

show    modulefile...

display modulefile...

Display information about one or more modulefiles. The display sub-command will list the full path of the modulefile(s) and all (or most) of the environment changes the modulefile(s) will make if loaded. (It will not display any environment changes found within conditional statements.)

list

List loaded modules.

avail [path...]

List all available modulefiles in the current MODULEPATH. All directories in the MODULEPATH are recursively searched for files containing the modulefile magic cookie. If an argument is given, then each directory in the MODULEPATH is searched for modulefiles whose pathname match the argument. Multiple versions of an application can be supported by creating a subdirectory for the application containing modulefiles for each version.

use [-a|--append] directory...

Prepend one or more directories to the MODULEPATH environment variable. The --append flag will append the directory to MODULEPATH.

unuse directory...

Remove one or more directories from the MODULEPATH environment variable.

update

Attempt to reload all loaded modulefiles. The environment will be reconfigured to match the environment saved in ${HOME}/.modulesbeginenv (if BEGINENV=1) or the file pointed at by $MODULESBEGINEV (if BEGINENV=99) and the modulefiles will be reloaded. This is only valid if modules was configured with --enable-beginenv (which defines BEGINENV), otherwise this will cause a warning. update will only change the environment variables that the modulefiles set.

clear

Force the Modules package to believe that no modules are currently loaded.

purge

Unload all loaded modulefiles.

refresh

Force a refresh of all non-persistent components of currently loaded modules. This should be used on derived shells where aliases need to be reinitialized but the environment variables have already been set by the currently loaded modules.

whatis [modulefile...]

Display the information set up by the module-whatis commands inside the specified modulefile(s). If no modulefile is specified, all 'whatis' lines will be shown.

apropos string

keyword string

Seeks through the 'whatis' informations of all modulefiles for the specified string. All module-whatis informations matching the string will be displayed.

initadd modulefile...

Add modulefile(s) to the shell's initialization file in the user's home directory. The startup files checked (in order) are:
csh - .modules, .cshrc(.ext), .csh_variables, and .login(.ext)
tcsh - .modules, .tcshrc, .cshrc(.ext), .csh_variables, and .login(.ext)
sh and ksh - .modules, .profile(.ext), and .kshenv(.ext)
bash - .modules, .bash_profile, .bash_login, .profile(.ext), and .bashrc(.ext)
zsh - .modules, .zcshrc(.ext), .zshenv(.ext), and .zlogin(.ext)

If a 'module load' line is found in any of these files, the modulefile(s) is(are) appended to any existing list of modulefiles. The 'module load' line must be located in at least one of the files listed above for any of the 'init' sub-commands to work properly. If the 'module load' line is found in multiple shell initialization files, all of the lines are changed.

initprepend modulefile [modulefile...]

Does the same as initadd but prepends the given modules to the beginning of the list.

initrm modulefile...

Remove modulefile(s) from the shell's initialization files.

initswitch modulefile1 modulefile2

Switch modulefile1 with modulefile2 in the shell's initialization files.

initlist

List all of the modulefiles loaded from the shell's initialization file.

initclear

Clear all of the modulefiles from the shell's initialization files.

Available Modules

Notice the modules on the cluster are always being updated, so the list here may not always be the most recent.  You can get the most recent list by running the "module avail" command on the cluster.