Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
services:modules [2019/07/25 10:19]
giunta [Searching For Modules] 		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 +
-   ​. ​  ​~/​.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 193: 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 202: Line 196:
    # module load git    # module load git
 endif endif
 +</​code>​
  
-===== User Collections ​=====+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:
  
-User defined initial list of login modules:+<​code>​ 
 +if [ -z "​$BASHRC_READ"​ ]; then 
 +   ​export BASHRC_READ=1 
 +   ​module --initial_load --no_redirect restore 
 +else 
 +   ​module refresh 
 +fi 
 +</​code>​
  
-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:+Csh users need specify ​the ''​module restore''​ command ​in their ''​~/​.cshrc''​ file:
  
-$ module unload XYZ +<​code>​ 
-$ module ​swap gcc ucc +if ( ! $?CSHRC_READ ) then 
-$ module ​load git +   ​setenv CSHRC_READ 1 
-Once users have the desired modules load then they issue:+  ​module ​--initial_load restore 
 +else 
 +  ​module ​refresh 
 +endif 
 +</​code>​
  
-$ module save +==== Tips for graphical login ====
-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 +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'':​
-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 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.+<​code>​ 
 +if [ "​$TERM"​ == "​xterm-256color"​ -a -z "​$BASHRC_READ"​ ]; then 
 +   ​export BASHRC_READ=1 
 +   # Place any module ​commands here 
 +   # ​module ​load git 
 +fi 
 +</​code>​
  
-Users can have as many collections as they like. They can save to a named collection with:+Csh users need to add in their ''​~/​.cshrc''​ file:
  
-$ module ​save <collection_name> +<​code>​ 
-and restore that named collection with:+if ( "$TERM" == "​xterm-256color"​ && ! $?​CSHRC_READ ) then 
 +   ​setenv CSHRC_READ 1 
 +   # Place any module ​command here 
 +   # module load git 
 +endif 
 +</code>
  
-$ module restore <​collection_name>​ +===== User Collections =====
-A user can print the contents of a collection with:+
  
-$ module describe <​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:
-A user can list the collections ​they have with:+
  
-$ module ​savelist +<​code>​ 
-Finally a user can disable a collection with:+$ module load cuda/9.0 
 +$ module load intel/​19.0.4.243 
 +$ module ​load hdf5/1.10.5 
 +</​code>​
  
-$ module disable <​collection_name>​ +and then issue:
-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+  ​$ module save
  
-===== Rules for loading ​modules ​from a collection =====+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
  
-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).+and only the desired modules will be loaded.
  
-Lmod records the fullName and the userName in the collection. +If a user doesn’t have a default ​collection, an error message ​is produced.
-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 +Users can have as many collections as they like. They can save to a named collection ​with:
-$ 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:+  $ module save <​collection_name>​
  
-$ module --force purge; module load A/1.0 B/2.3 C/3.4 +and restore that named collection with:
-$ 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 +  $ module restore <​collection_name>​
-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:+A user can print the contents of a collection with:
  
-$ module ​savelist+  ​$ module ​describe <​collection_name>​
  
-  1) default +A user can list the collections they have with:
-where the default file is named “default.A”. +
-===== 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.+  $ module ​savelist
  
-On all workstations the modules package is available as standard; it provides for the dynamic modification of the user's environment via modulefiles.+Finally a user can disable a collection with:
  
-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.+  $ module ​disable <​collection_name>​
  
-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:+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:
  
-<​xterm>​ +  $ cd ~/.lmod.d; mv foo~ foo
-[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>​ +==== Rules for loading modules from a collection ====
-[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"​''​.+//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.
  
-==== load ==== +  - //module// records the //​fullName//​ and the //​userName//​ in the collection. 
-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.)+  - 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.
  
-<​xterm>​ +In other words if a user does:
-[user@workstation ~]# **module load cce** +
-</​xterm>​+
  
-==== list ==== +  $ module --force purge; module load A B C 
-This lists all modules which are currently loaded into the users' environment (versions or names may change).+  $ module save
  
-<​xterm>​ +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.
-[user@workstation ~]# **module ​list** +
-Currently Loaded Modulefiles:​ +
- 1) cce/10.1.013  +
-</xterm>+
  
-==== unload ==== +On the other hand:
-Use this command to unload one or more of the loaded module files (seen in ''​list''​ before).+
  
-<​xterm>​ +  $ module ​--force purge; module load A/1.0 B/2.3 C/3.4 
-[user@workstation ~]# **module ​unload cce** +  $ module save
-</xterm>+
  
-==== whatis ==== +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.
-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>​+