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 12:50] giunta [User Collections] |
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 179: | Line 174: | ||
| ===== Controlling Modules During Login ===== | ===== Controlling Modules During Login ===== | ||
| - | 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. | + | <note warning>Automatically loaded modules may have a negative effect on GNOME graphical login</note> |
| - | 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: | + | 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: |
| - | if [ -f ~/.bashrc ]; then | + | <code> |
| - | . ~/.bashrc | + | if [ -z "$BASHRC_READ" ]; then |
| + | export BASHRC_READ=1 | ||
| + | # Place any module commands here | ||
| + | # module load git | ||
| fi | fi | ||
| - | and place the following in their ~/.bashrc file: | + | </code> |
| + | 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 | ||
| + | setenv CSHRC_READ 1 | ||
| + | # Place any module command here | ||
| + | # module load git | ||
| + | endif | ||
| + | </code> | ||
| + | |||
| + | 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: | ||
| + | |||
| + | <code> | ||
| if [ -z "$BASHRC_READ" ]; then | if [ -z "$BASHRC_READ" ]; then | ||
| + | export BASHRC_READ=1 | ||
| + | module --initial_load --no_redirect restore | ||
| + | else | ||
| + | module refresh | ||
| + | fi | ||
| + | </code> | ||
| + | |||
| + | Csh users need specify the ''module restore'' command in their ''~/.cshrc'' file: | ||
| + | |||
| + | <code> | ||
| + | if ( ! $?CSHRC_READ ) then | ||
| + | setenv CSHRC_READ 1 | ||
| + | module --initial_load restore | ||
| + | else | ||
| + | module refresh | ||
| + | endif | ||
| + | </code> | ||
| + | |||
| + | ==== Tips for graphical login ==== | ||
| + | |||
| + | 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'': | ||
| + | |||
| + | <code> | ||
| + | if [ "$TERM" == "xterm-256color" -a -z "$BASHRC_READ" ]; then | ||
| export BASHRC_READ=1 | export BASHRC_READ=1 | ||
| # Place any module commands here | # Place any module commands here | ||
| # 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: | + | Csh users need to add in their ''~/.cshrc'' file: |
| - | if ( ! $?CSHRC_READ ) then | + | <code> |
| + | if ( "$TERM" == "xterm-256color" && ! $?CSHRC_READ ) then | ||
| setenv CSHRC_READ 1 | setenv CSHRC_READ 1 | ||
| # Place any module command here | # Place any module command here | ||
| # module load git | # module load git | ||
| endif | endif | ||
| + | </code> | ||
| ===== User Collections ===== | ===== User Collections ===== | ||
| Line 249: | Line 288: | ||
| $ cd ~/.lmod.d; mv foo~ foo | $ cd ~/.lmod.d; mv foo~ foo | ||
| - | ===== Rules for loading modules from a collection ===== | + | ==== 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. | ||
| - | 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// 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. | ||
| - | Lmod 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: | In other words if a user does: | ||
| - | $ module --force purge; module load A B C | + | $ 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. | + | |
| + | 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: | On the other hand: | ||
| - | $ module --force purge; module load A/1.0 B/2.3 C/3.4 | + | $ module --force purge; module load A/1.0 B/2.3 C/3.4 |
| - | $ module save | + | $ 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 | + | |
| - | 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: | + | |
| - | + | ||
| - | $ module savelist | + | |
| - | 1) default | + | 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. |
| - | where the default file is named “default.A”. | + | |