Actions

Difference between revisions of "Purging all modules"

From ALICE Documentation

Line 1: Line 1:
 
====  Purging all modules  ====
 
====  Purging all modules  ====
 
In order to unload all modules at once, and hence be sure to start in a clean state, you can use:  
 
In order to unload all modules at once, and hence be sure to start in a clean state, you can use:  
   $ module purge
+
   $ '''module purge'''
 
This is always safe: the cluster module (the module that specifies which cluster jobs will get submitted to) will not be unloaded (because it’s a so-called “sticky” module).
 
This is always safe: the cluster module (the module that specifies which cluster jobs will get submitted to) will not be unloaded (because it’s a so-called “sticky” module).
   $ module load example
+
 
 +
==== Using explicit version numbers ====
 +
Once a module has been installed on the cluster, the exe cutables or libraries it comprises are never modified. This policy ensures that the user’s programs will run consistently, at least if the user specifies a specific version. Failing to specify a version may result in unexpected behaviour. Consider the following example: the user decides to use the example module and at that point in time, just a single version 1.2.3 is installed on the cluster. The user loads the module using:
 +
   $ '''module load example'''
 
rather than  
 
rather than  
   $ module load example/1.2.3
+
   $ '''module load example/1.2.3'''
 
Everything works fine, up to the point where a new version of example is installed, 4.5.6. From then on, the user’s load command will load the latter version, rather than the intended one, which may lead to unexpected problems. See for example section 8.8.  
 
Everything works fine, up to the point where a new version of example is installed, 4.5.6. From then on, the user’s load command will load the latter version, rather than the intended one, which may lead to unexpected problems. See for example section 8.8.  
  
 
Consider the following example modules:  
 
Consider the following example modules:  
   $ module avail example/  
+
   $ '''module avail example/'''
 
   example/1.2.3  
 
   example/1.2.3  
 
   example/4.5.6
 
   example/4.5.6
 
Let’s now generate a version conflict with the example module, and see what happens.  
 
Let’s now generate a version conflict with the example module, and see what happens.  
   $ module av example/  
+
   $ '''module av example/'''
 
   example/1.2.3        example/4.5.6  
 
   example/1.2.3        example/4.5.6  
   $ module load example/1.2.3 example/4.5.6  
+
   $ '''module load example/1.2.3 example/4.5.6'''
 
   Lmod has detected the following error: A different version of the ’example’ module is already loaded (see output of ’ml’).  
 
   Lmod has detected the following error: A different version of the ’example’ module is already loaded (see output of ’ml’).  
   $ module swap example/4.5.6
+
   $ '''module swap example/4.5.6'''
  
 
Note: A module swap command combines the appropriate module unload and module load commands.
 
Note: A module swap command combines the appropriate module unload and module load commands.

Revision as of 14:29, 17 April 2020

Purging all modules

In order to unload all modules at once, and hence be sure to start in a clean state, you can use:

 $ module purge

This is always safe: the cluster module (the module that specifies which cluster jobs will get submitted to) will not be unloaded (because it’s a so-called “sticky” module).

Using explicit version numbers

Once a module has been installed on the cluster, the exe cutables or libraries it comprises are never modified. This policy ensures that the user’s programs will run consistently, at least if the user specifies a specific version. Failing to specify a version may result in unexpected behaviour. Consider the following example: the user decides to use the example module and at that point in time, just a single version 1.2.3 is installed on the cluster. The user loads the module using:

 $ module load example

rather than

 $ module load example/1.2.3

Everything works fine, up to the point where a new version of example is installed, 4.5.6. From then on, the user’s load command will load the latter version, rather than the intended one, which may lead to unexpected problems. See for example section 8.8.

Consider the following example modules:

 $ module avail example/ 
 example/1.2.3 
 example/4.5.6

Let’s now generate a version conflict with the example module, and see what happens.

 $ module av example/ 
 example/1.2.3        example/4.5.6 
 $ module load example/1.2.3 example/4.5.6 
 Lmod has detected the following error: A different version of the ’example’ module is already loaded (see output of ’ml’). 
 $ module swap example/4.5.6

Note: A module swap command combines the appropriate module unload and module load commands.