Utiliser des modules/en: Difference between revisions

<languages />

A "modulefile" contains the information needed to make an application or library available in the user's login session. Typically a module file contains instructions that modify or initialize environment variables such as <code>PATH</code> and <code>LD_LIBRARY_PATH</code> in order to use different installed programs. Note that the simple fact of loading a module doesn't execute the software in question. To learn the name of the program binary or the syntax for its use, you should read the documentation for this software. By using the <tt>module</tt> command, you shouldn't normally need to know the exact location or path of the software or library but you can nevertheless see such details about the module by means of the command <tt>module show <module-name></tt>.

= Important <code>module</code> commands =

{{Command | module command [other options]}}

To see a list of available sub-commands use

{{Command|module help}}

== Sub-command <code>avail</code> ==

To list the modules available on a given system, use

{{Command|module avail}}

You can obtain a list of modules available for a particular library or tool, for example modules related to <code>openmpi</code>:

{{Command|module avail openmpi}}

== Sub-command <code>spider</code> (Lmod only) ==

The <code>spider</code> sub-command searches the complete tree of all modules and displays it.

{{Command|module spider}}

If you specify the name of an application, for example with

{{Command|module spider openmpi}}

If you specify the name of the application along with a version number, for example with

{{Command|module spider openmpi/1.8.4}}

this will display a list of the modules you must load in order to access this version.

== Sub-command <code>list</code> ==

If you load a module that is incompatible with one you already have loaded, Lmod will tell you that it has replaced the old module with a new one. This can occur especially for compilers and MPI implementations.  

== Sub-command <code>unload</code> ==

After the <code>load</code> sub-command, <code>unload</code> removes a module from your environment. For example,

{{Command|module unload gcc/4.8}}

If you have other modules loaded that depend on this compiler, Lmod will tell you that they have been disabled.

The sub-command <code>purge</code> allows you to remove all the modules you have loaded in one go.

Some modules may be marked "sticky" (permanent) by system administrators. These will not be unloaded.

== Sub-commands <code>show, help</code> and <code>whatis</code> ==

The sub-commands <code>show, help</code> and <code>whatis</code> provide additional information about a given module. The <code>show</code> sub-command displays the entire module, <code>help</code> displays a help message, and <code>whatis</code> shows a description of the module.

== Sub-command <code>apropos</code> or <code>keyword</code> ==

The sub-commands <code>apropos</code> or <code>keyword</code> allow you to search for a keyword in all modules. If you don't know which module is appropriate for your calculation, you can search the description.

= Loading modules automatically =

= Module collections (Lmod only) =

Lmod allows you to create a collection of modules. To do so, first load the desired modules. For example:

{{Command|module load gcc/4.8 openmpi/1.8 mkl}}

Then use the <code>save</code> sub-command to save this collection:

{{Command|module save my_modules}}

Then in a later session or in a job you can restore the collection with the command

Some modules are hidden. You may ignore them. They are typically modules that you don't have to load manually. They are loaded automatically based on other modules.  

= Lmod vs Environment Modules =

== Module hierarchy ==

Most systems use a flat module structure: All modules are at the same level. This becomes problematic when many combinations of versions of different modules are available on a system. For example, if you need to use the [[FFTW]] library and the module <code>fftw</code> is available in several versions, including a version compiled with GCC 4.8 and Open MPI 1.6, you might see modules named <code>openmpi/1.6_gcc4.8</code> and <code>fftw/3.3_gcc4.8_openmpi1.6</code>. This is neither elegant nor practical. To solve this problem we use a hierarchy of modules. Rather than using the command

you instead use

{{Command|module load gcc/4.8 openmpi/1.6 fftw/3.3}}

The inconvenience of using a module hierarchy is that, since modules can have the same name, only the modules that are compatible with the "parent" modules are displayed by the <code>module avail</code> command. Loading a parent module is therefore a prerequisite to loading some modules. To get complete information, Lmod provides the <code>module spider</code> command. It scans the entire hierarchy and displays all the modules. By specifying a module and a particular version, it is then possible to see which paths in the hierarchy enable the desired module to be loaded.

== Module collections ==

Module collections are an additional functionality provided by Lmod. See [[#Module collections (Lmod only)|this section]] for more details.

== Only one version loaded at a time ==

Lmod will refuse to load two versions of the same module at the same time. For example, you cannot have versions 4.8 and 5.4 of the GCC compilers loaded at once.

== Only one module in the same family loaded at a time ==

== Automatic replacement of modules ==

== Permanent modules ==

= Creating modules =  

For instructions about creating modules, please refer to the [http://lmod.readthedocs.io/en/latest/015_writing_modules.html official documentation].  

= Using modules with ZSH or KSH =

If you wish to use modules with the ZSH or KSH shell, execute the appropriate following command:

{{Command|source $LMOD_PKG/init/zsh}}

{{Command|source $LMOD_PKG/init/ksh}}