Differences

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

--- services:modules [2019/07/25 10:19]
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:
-  $ 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
-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:
@@ Line 77: / Line 73: @@
 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
 ===== Specifying modules to load =====
@@ Line 179: / Line 174: @@
 ===== 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
-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
+   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
    # Place any module commands here
    # module load git
 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
    # Place any module command here
    # module load git
 endif
+</code>
 ===== User Collections =====
-User defined initial list of login modules:
+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:
-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:
+<code>
+$ module load cuda/9.0
+$ module load intel/19.0.4.243
+$ module load hdf5/1.10.5
+</code>
-$ module unload XYZ
+and then issue:
-$ module swap gcc ucc
-$ module load git
-Once users have the desired modules load then they issue:
-$ module save
+  $ module save
-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
+This creates a file called ''~/.lmod.d/default'' which has the list of desired modules. Once this is set-up, a user can issue:
-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.
+  $ module restore
+and only the desired modules will be loaded.
+If a user doesn’t have a default collection, an error message is produced.
 Users can have as many collections as they like. They can save to a named collection with:
-$ module save <collection_name>
+  $ module save <collection_name>
 and restore that named collection with:
-$ module restore <collection_name>
+  $ module restore <collection_name>
 A user can print the contents of a collection with:
-$ module describe <collection_name>
+  $ module describe <collection_name>
 A user can list the collections they have with:
-$ module savelist
+  $ module savelist
 Finally a user can disable a collection with:
-$ module disable <collection_name>
+  $ 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
+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:
-===== Rules for loading modules from a collection =====
+  $ cd ~/.lmod.d; mv foo~ foo
+==== Rules for loading modules from a collection ====
-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// 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.
-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:
-$ 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.
-On the other hand:
+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.
-$ module --force purge; module load A/1.0 B/2.3 C/3.4
+On the other hand:
-$ 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
+  $ module --force purge; module load A/1.0 B/2.3 C/3.4
+  $ module save
-) 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”.