Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
services:modules [2019/07/25 10:05] giunta |
services:modules [2019/07/25 14:34] (current) giunta [Tips for graphical login] |
||
|---|---|---|---|
| Line 32: | Line 32: | ||
| A user may wish to go back to an initial set of modules: | A user may wish to go back to an initial set of modules: | ||
| - | |||
| - | $ module reset | ||
| - | |||
| - | This will unload all currently loaded modules, including the sticky ones, then load the list of modules specified by LMOD_SYSTEM_DEFAULT_MODULES. There is a related command: | ||
| $ module restore | $ module restore | ||
| - | This command will also unload all currently loaded modules, including the sticky ones, and then load the system default unless the user has a default collection. See User Collections for more details. | + | This command will also unload all currently loaded modules, including the sticky ones, and then load the user's default collection. See [[services:modules#user_collections|User Collections]] for more details. |
| If a module is not available then an error message is produced: | If a module is not available then an error message is produced: | ||
| Line 77: | Line 73: | ||
| This will search any help message or whatis description for the word(s) given on the command line. | This will search any help message or whatis description for the word(s) given on the command line. | ||
| - | Another way to search for modules is with the ''module spider''command. This command searches the entire list of possible modules. The difference between ''module avail'' and ''module spider'' is explained in the “Module Hierarchy” and “Searching for Modules” section.: | + | Another way to search for modules is with the ''module spider''command. This command searches the entire list of possible modules. The difference between ''module avail'' and ''module spider'' is explained in the [[services:modules#module_hierarchy|Module Hierarchy]] and [[services:modules#searching_for_modules|Searching for Modules]] section: |
| $ module spider | $ module spider | ||
| - | |||
| ===== Specifying modules to load ===== | ===== Specifying modules to load ===== | ||
| Line 177: | Line 172: | ||
| </code> | </code> | ||
| - | Controlling Modules During Login | + | ===== Controlling Modules During Login ===== |
| + | <note warning>Automatically loaded modules may have a negative effect on GNOME graphical login</note> | ||
| - | Normally when a user logs in, there are a standard set of modules that are automatically loaded. Users can override and add to this standard set in two ways. The first is adding module commands to their personal startup files. The second way is through the “module save” command. | + | Users can automatically load a standard set of modules when log in, adding module commands to their //personal startup files//. To add module commands to users’ startup scripts, Bash users need to place the following in their ''~/.bashrc'' file: |
| - | + | ||
| - | To add module commands to users’ startup scripts requires a few steps. Bash users can put the module commands in either their ~/.profile file or their ~/.bashrc file. It is simplest to place the following in their ~/.profile file: | + | |
| - | + | ||
| - | if [ -f ~/.bashrc ]; then | + | |
| - | . ~/.bashrc | + | |
| - | fi | + | |
| - | and place the following in their ~/.bashrc file: | + | |
| + | <code> | ||
| if [ -z "$BASHRC_READ" ]; then | if [ -z "$BASHRC_READ" ]; then | ||
| export BASHRC_READ=1 | export BASHRC_READ=1 | ||
| Line 194: | Line 184: | ||
| # module load git | # module load git | ||
| fi | fi | ||
| - | By wrapping the module command in an if test, the module commands need only be read in once. Any sub-shell will inherit the PATH and other environment variables automatically. On login shells the ~/.profile file is read which, in the above setup, causes the ~/.bashrc file to be read. On interactive non-login shells, the ~/.bashrc file is read instead. Obviously, having this setup means that module commands need only be added in one file and not two. | + | </code> |
| - | Csh users need only specify the module commands in their ~/.cshrc file as that file is always sourced: | + | By wrapping the module command in an //if// test, the module commands need only be read in once. Any sub-shell will inherit the ''PATH'' and other environment variables automatically. |
| + | Csh users need specify the module commands in their ''~/.cshrc'' file: | ||
| + | |||
| + | <code> | ||
| if ( ! $?CSHRC_READ ) then | if ( ! $?CSHRC_READ ) then | ||
| setenv CSHRC_READ 1 | setenv CSHRC_READ 1 | ||
| Line 203: | Line 196: | ||
| # module load git | # module load git | ||
| endif | endif | ||
| - | User Collections | + | </code> |
| - | User defined initial list of login modules: | + | |
| - | Assuming that the system administrators have installed Lmod correctly, there is a second way which is much easier to setup. A user logs in with the standard modules loaded. Then the user modifies the default setup through the standard module commands: | + | If users have created at least a default collection (see [[services:modules#user_collections|User Collections]] for more details), they can replace all ''module load ...'' commands with a single ''module restore''. Bash users need to place the following in their ''~/.bashrc'' file: |
| - | $ module unload XYZ | + | <code> |
| - | $ module swap gcc ucc | + | if [ -z "$BASHRC_READ" ]; then |
| - | $ module load git | + | export BASHRC_READ=1 |
| - | Once users have the desired modules load then they issue: | + | module --initial_load --no_redirect restore |
| + | else | ||
| + | module refresh | ||
| + | fi | ||
| + | </code> | ||
| - | $ module save | + | Csh users need specify the ''module restore'' command in their ''~/.cshrc'' file: |
| - | This creates a file called ~/.lmod.d/default which has the list of desired modules. Once this is set-up a user can issue: | + | |
| - | $ module restore | + | <code> |
| - | and only the desired modules will be loaded. If Lmod is setup correctly (see Providing A Standard Set Of Modules for all Users) then the default collection will be the user’s initial set of modules. | + | if ( ! $?CSHRC_READ ) then |
| + | setenv CSHRC_READ 1 | ||
| + | module --initial_load restore | ||
| + | else | ||
| + | module refresh | ||
| + | endif | ||
| + | </code> | ||
| - | If a user doesn’t have a default collection, the Lmod purges ALL currently loaded modules, including the sticky ones, and loads the list of module specified by LMOD_SYSTEM_DEFAULT_MODULES just like the module reset command. | + | ==== Tips for graphical login ==== |
| - | Users can have as many collections as they like. They can save to a named collection with: | + | When using automatically loaded modules, a possible solution to avoid problems on GNOME login could be testing ''TERM'' environment variable. In this way, only when users open a graphical terminal (e.g., GNOME Terminal), modules will be loaded. On SISSA linux workstations, //GNOME Terminal// sets it as ''xterm-256color''. Bash users may add a test on ''TERM'' variable in their ''~/.bashrc'': |
| - | $ module save <collection_name> | + | <code> |
| - | and restore that named collection with: | + | if [ "$TERM" == "xterm-256color" -a -z "$BASHRC_READ" ]; then |
| + | export BASHRC_READ=1 | ||
| + | # Place any module commands here | ||
| + | # module load git | ||
| + | fi | ||
| + | </code> | ||
| - | $ module restore <collection_name> | + | Csh users need to add in their ''~/.cshrc'' file: |
| - | A user can print the contents of a collection with: | + | |
| - | $ module describe <collection_name> | + | <code> |
| - | A user can list the collections they have with: | + | if ( "$TERM" == "xterm-256color" && ! $?CSHRC_READ ) then |
| + | setenv CSHRC_READ 1 | ||
| + | # Place any module command here | ||
| + | # module load git | ||
| + | endif | ||
| + | </code> | ||
| - | $ module savelist | + | ===== User Collections ===== |
| - | Finally a user can disable a collection with: | + | |
| - | $ module disable <collection_name> | + | Users can defined //lists// (collections) of modules to load with a single command. To define the //default// collection, users have to load the desired modules, for example: |
| - | If no collection_name is given then the default is disabled. Note that the collection is not remove just renamed. If a user disables the foo collection, the file foo is renamed to foo~. To restore the foo collection, a user will have to do the following: | + | |
| - | $ cd ~/.lmod.d; mv foo~ foo | + | <code> |
| - | Rules for loading modules from a collection | + | $ module load cuda/9.0 |
| - | Lmod has rules on what modules to load when restoring a collection. Remember that userName is what the user asked for, the fullName is the exact module name and shortName is name of the package (e.g. gcc, fftw3). | + | $ module load intel/19.0.4.243 |
| + | $ module load hdf5/1.10.5 | ||
| + | </code> | ||
| - | Lmod records the fullName and the userName in the collection. | + | and then issue: |
| - | If the userName is the same as the fullName then it loads fullName independent of the default. | + | |
| - | if the userName is not the same as the fullName then it loads the default. | + | |
| - | Unless LMOD_PIN_VERSIONS=yes then the fullName is always loaded. | + | |
| - | In other words if a user does: | + | |
| - | $ module --force purge; module load A B C | + | $ module save |
| - | $ module save | + | |
| - | then “module restore” will load the default A, B, and C. So if the default for module A changed between when the collection was saved and then restored, a new version of A will be loaded. This assumes that LMOD_PIN_VERSIONS is not set. If it is set or Lmod is configured that way then if A/1.1, B/2.4 and C/3.3 are the default then those modules will be loaded in the future independent of what the defaults are in the future. | + | |
| - | On the other hand: | + | This creates a file called ''~/.lmod.d/default'' which has the list of desired modules. Once this is set-up, a user can issue: |
| - | $ module --force purge; module load A/1.0 B/2.3 C/3.4 | + | $ module restore |
| - | $ module save | + | |
| - | then “module restore” will load the A/1.0, B/2.3, and C/3.4 independent of what the defaults are now or in the future. | + | |
| - | User Collections on shared home file systems | + | and only the desired modules will be loaded. |
| - | If your site has a shared home file system, then things become a little more complicated. A shared home file system means that your site has a single home file system shared between two or more clusters. See Lmod on Shared Home File Systems for a system administrators point of view. | + | |
| - | If you have a collection on one cluster it needs to be independent of another cluster. Your site should set $LMOD_SYSTEM_NAME uniquely for each cluster. Suppose you have cluster A and B. Then $LMOD_SYSTEM_NAME will be either A or B. A default collection will be named “default.A” for the A cluster and “default.B” for the B cluster. The names a user sees will have the extension removed. In other words on the A cluster a user would see: | + | If a user doesn’t have a default collection, an error message is produced. |
| - | $ module savelist | + | Users can have as many collections as they like. They can save to a named collection with: |
| - | 1) default | + | $ module save <collection_name> |
| - | where the default file is named “default.A”. | + | |
| + | and restore that named collection with: | ||
| + | $ module restore <collection_name> | ||
| + | A user can print the contents of a collection with: | ||
| + | $ module describe <collection_name> | ||
| + | A user can list the collections they have with: | ||
| + | $ module savelist | ||
| + | Finally a user can disable a collection with: | ||
| + | $ module disable <collection_name> | ||
| + | If no //collection_name// is given then the //default// is disabled. Note that the collection is not remove just renamed. If a user disables the //foo// collection, the file //foo// is renamed to //foo~//. To restore the foo collection, a user will have to do the following: | ||
| + | $ cd ~/.lmod.d; mv foo~ foo | ||
| + | ==== Rules for loading modules from a collection ==== | ||
| + | //module// has rules on what modules to load when restoring a collection. In this guide, we call ''gnu8/8.3.0'' the //fullName// of the module and ''gnu8'' as the //shortName//. We also call what the user asked for as the //userName// which could either be the //fullName// or the //shortName// depending on what the user typed on the command line. | ||
| + | - //module// records the //fullName// and the //userName// in the collection. | ||
| + | - If the //userName// **is the same** as the //fullName// then it loads //fullName// independent of the default. | ||
| + | - if the //userName// **is not the same** as the //fullName// then it loads the default. | ||
| + | - Unless ''LMOD_PIN_VERSIONS=yes'' then the //fullName// is always loaded. | ||
| + | In other words if a user does: | ||
| + | $ module --force purge; module load A B C | ||
| + | $ module save | ||
| + | then ''module restore'' will load the default A, B, and C. So if the default for module A changed between when the collection was saved and then restored, a new version of A will be loaded. This assumes that ''LMOD_PIN_VERSIONS'' is not set. If it is set then if A/1.1, B/2.4 and C/3.3 are the default then those modules will be loaded in the future independent of what the defaults are in the future. | ||
| + | On the other hand: | ||
| + | $ module --force purge; module load A/1.0 B/2.3 C/3.4 | ||
| + | $ module save | ||
| - | + | then ''module restore'' will load the A/1.0, B/2.3, and C/3.4 independent of what the defaults are now or in the future. | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | ===== Usage ===== | + | |
| - | The workstations have a variety of compilers, libraries, and other bits of software installed. Some of it exists in multiple versions, and, for example, you may wish to switch between compilers for testing or you may wish to select a specific revision of Matlab. | + | |
| - | + | ||
| - | The purpose of the module package is to simplify this for you. | + | |
| - | + | ||
| - | On all workstations the modules package is available as standard; it 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; 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. | + | |
| - | + | ||
| - | 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: | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module** | + | |
| - | Modules Release Tcl x.x.x ($RCSfile: modulecmd.tcl,v $ $Revision: x.xxx $) | + | |
| - | Copyright GNU GPL v2 1991 | + | |
| - | Usage: module [ switches ] [ command ] | + | |
| - | Switches: | + | |
| - | -t terse format avail and list | + | |
| - | -l long format avail and list | + | |
| - | Commands: | + | |
| - | list | add|load modulefile [modulefile ...] | + | |
| - | purge | rm|unload modulefile [modulefile ...] | + | |
| - | reload | switch|swap [oldmodulefile] newmodulefile | + | |
| - | | display|show modulefile [modulefile ...] | + | |
| - | | avail [modulefile [modulefile ...]] | + | |
| - | | whatis [modulefile [modulefile ...]] | + | |
| - | | help [modulefile [modulefile ...]] | + | |
| - | | path modulefile | + | |
| - | | paths modulefile | + | |
| - | | use dir [dir ...] | + | |
| - | | unuse dir [dir ...] | + | |
| - | | source scriptfile | + | |
| - | | apropos|keyword string | + | |
| - | | | + | |
| - | initlist | initadd modulefile | + | |
| - | initclear | initprepend modulefile | + | |
| - | | initrm modulefile | + | |
| - | </xterm> | + | |
| - | ===== Sub-Commands ===== | + | |
| - | ==== avail ==== | + | |
| - | With the subcommand ''avail'' you get available list of module files (versions or names may change): | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module avail** | + | |
| - | ------------ /u/shared/programs/noarch/common/modulefiles ------------ | + | |
| - | mathematica/6.0.2(default) mkl/10.0.2.018(default) | + | |
| - | mathematica/6.0.1 mkl/9.0.1 | + | |
| - | ------------ /u/shared/programs/x86_64/common/modulefiles ------------ | + | |
| - | cce/10.1.013(default) intel/10.1.013(default) pgi/7.1-6(default) | + | |
| - | cce/9.0.1 intel/9.1 pgi/6.1 | + | |
| - | fce/10.1.013(default) maple/11(default) sm/2.4.34(default) | + | |
| - | fce/9.1 maple/10 sm/2.2.3 | + | |
| - | idbe/10.1.013(default) matlab/2007b(default) | + | |
| - | idbe/9.1 matlab/2007a | + | |
| - | </xterm> | + | |
| - | + | ||
| - | The notation for the modulefilename is ''"name of the application/version and description"''. | + | |
| - | + | ||
| - | ==== load ==== | + | |
| - | To use a particular module, run ''module load modulename''. You don't need to list the full name of the module, as listed in ''module avail'' output, if you only use the first component, it will choose the latest version for you. (It actually chooses the last item alphabetically.) | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module load cce** | + | |
| - | </xterm> | + | |
| - | + | ||
| - | ==== list ==== | + | |
| - | This lists all modules which are currently loaded into the users' environment (versions or names may change). | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module list** | + | |
| - | Currently Loaded Modulefiles: | + | |
| - | 1) cce/10.1.013 | + | |
| - | </xterm> | + | |
| - | + | ||
| - | ==== unload ==== | + | |
| - | Use this command to unload one or more of the loaded module files (seen in ''list'' before). | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module unload cce** | + | |
| - | </xterm> | + | |
| - | + | ||
| - | ==== whatis ==== | + | |
| - | If a module looks interesting, use this command to display the information contained within the given module file (versions or names may change). | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module whatis cce** | + | |
| - | ----------- /u/shared/programs/noarch/common/modulefiles ------------- | + | |
| - | ----------- /u/shared/programs/x86_64/common/modulefiles ------------- | + | |
| - | cce/10.1.013: loads the Intel(R) C++ Compiler 10.1.013 | + | |
| - | </xterm> | + | |
| - | + | ||
| - | ==== display ==== | + | |
| - | Use this command to see exactly what a given modulefile will do to your environment, such as what will be added to the PATH, MANPATH, etc. environment variables. | + | |
| - | + | ||
| - | <xterm> | + | |
| - | [user@workstation ~]# **module display cce** | + | |
| - | ------------------------------------------------------------------- | + | |
| - | /u/shared/programs/x86_64/common/modulefiles/cce/10.1.013: | + | |
| - | + | ||
| - | module-whatis loads the Intel(R) C++ Compiler 10.1.013 | + | |
| - | prepend-path PATH /u/shared/programs/x86_64/common/intel/cce/10.1.013/bin | + | |
| - | prepend-path LD_LIBRARY_PATH /u/shared/programs/x86_64/common/intel/cce/10.1.013/lib | + | |
| - | prepend-path MANPATH /u/shared/programs/x86_64/common/intel/cce/10.1.013/man | + | |
| - | prepend-path INTEL_LICENSE_FILE /u/shared/licenses/intel | + | |
| - | ------------------------------------------------------------------- | + | |
| - | </xterm> | + | |
| - | + | ||
| - | ===== Using modules in batch ===== | + | |
| - | To automatically load modules when you log in to a system, put the ''module load modulename'' command in your shell's startup script. | + | |
| - | + | ||
| - | For example: | + | |
| - | + | ||
| - | * if your shell is ''bash'', put the command in your ''~/.bashrc'' | + | |
| - | * if your shell is ''csh'', put it in your ''~/.cshrc''. | + | |
| - | + | ||
| - | If you change shells in your batch script you may need to explicitly load the modules environment (if your script does not use modules commands, there is, of course, no need to do this) by adding as the first line of your ''bash'' script: | + | |
| - | + | ||
| - | <code> | + | |
| - | . /etc/profile.d/modules.sh | + | |
| - | </code> | + | |
| - | + | ||
| - | or in case your script is ''csh'' derived: | + | |
| - | + | ||
| - | <code> | + | |
| - | source /etc/profile.d/modules.csh | + | |
| - | </code> | + | |