rsnt_translations
56,420
edits
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
<!--T:35--> | <!--T:35--> | ||
Les modules sont des fichiers de configuration qui contiennent des instructions pour modifier votre environnement logiciel. Cette architecture modulaire permet d'avoir plusieurs versions d'une même application installées sans que celles-ci entrent en conflit. Pour les nouveaux serveurs, les modules sont gérés par l'outil [https://www.tacc.utexas.edu/research-development/tacc-projects/lmod Lmod] | Les modules sont des fichiers de configuration qui contiennent des instructions pour modifier votre environnement logiciel. Cette architecture modulaire permet d'avoir plusieurs versions d'une même application installées sans que celles-ci entrent en conflit. Pour les nouveaux serveurs, les modules sont gérés par l'outil [https://www.tacc.utexas.edu/research-development/tacc-projects/lmod Lmod] développé au [https://www.tacc.utexas.edu/ TACC]. Cet outil remplace [http://modules.sourceforge.net ''Environment Modules''] qui est utilisé sur la plupart des anciens serveurs. Si vous le connaissez, vous ne devriez pas être trop dépaysé, car ''Lmod'' a été conçu pour être très similaire à ''Environment Modules''. Référez-vous à la section [[Utiliser des modules#Lmod_vs_Environment_Modules|Lmod vs Environment Modules]] ci-dessous pour connaître les différences principales. | ||
<!--T:3--> | <!--T:3--> | ||
Un fichier module (''modulefile'') contient les informations nécessaires pour rendre disponible une application ou une bibliothèque dans la session de l'usager. Typiquement, un fichier module contient des instructions qui modifient ou initialisent les variables d'environnement comme <tt>PATH</tt> et <tt>LD_LIBRARY_PATH</tt> pour utiliser les différents logiciels installés. Notez que le simple fait de charger un module n'exécute pas le logiciel dont il est question. Pour connaître le nom du fichier binaire et la syntaxe de son usage il faut lire la documentation du logiciel et avec | Un fichier module (''modulefile'') contient les informations nécessaires pour rendre disponible une application ou une bibliothèque dans la session de l'usager. Typiquement, un fichier module contient des instructions qui modifient ou initialisent les variables d'environnement comme <tt>PATH</tt> et <tt>LD_LIBRARY_PATH</tt> pour utiliser les différents logiciels installés. Notez que le simple fait de charger un module n'exécute pas le logiciel dont il est question. Pour connaître le nom du fichier binaire et la syntaxe de son usage, il faut lire la documentation du logiciel et avec la commande <tt>module</tt>, vous n'avez normalement pas besoin de connaître le chemin du logiciel ou de la bibliothèque. Vous pouvez | ||
voir des détails pour le module en tapant la commande <tt>module show <nom de module></tt>. | |||
= Principales commandes de <tt>module</tt> = <!--T:4--> | = Principales commandes de <tt>module</tt> = <!--T:4--> | ||
Line 30: | Line 31: | ||
Si vous spécifiez le nom de l'application avec son numéro de version, par exemple avec | Si vous spécifiez le nom de l'application avec son numéro de version, par exemple avec | ||
{{Commande|module spider openmpi/1.8.4}} | {{Commande|module spider openmpi/1.8.4}} | ||
cela | cela affichera la liste des options de module à charger afin d'accéder à cette version. | ||
== Sous-commande <tt>avail</tt> == <!--T:9--> | == Sous-commande <tt>avail</tt> == <!--T:9--> | ||
Line 62: | Line 63: | ||
== Sous-commande <tt>unload</tt> == <!--T:16--> | == Sous-commande <tt>unload</tt> == <!--T:16--> | ||
Au contraire de la sous-commande '''<tt>load</tt>''', '''<tt>unload</tt>''' enlève un module de votre environnement. Par exemple | |||
{{Commande|module unload gcc/4.8}} | {{Commande|module unload gcc/4.8}} | ||
enlèverait le compilateur GCC 4.8 de votre environnement. | enlèverait le compilateur GCC 4.8 de votre environnement. | ||
Line 74: | Line 75: | ||
<!--T:19--> | <!--T:19--> | ||
Certains modules peuvent être marqués comme ''sticky'' ( | Certains modules peuvent être marqués comme ''sticky'' (permanents) par les administrateurs de système et ne seront pas enlevés. | ||
== Sous-commandes <tt>show</tt>, <tt>help</tt> et <tt>whatis</tt> == <!--T:20--> | == Sous-commandes <tt>show</tt>, <tt>help</tt> et <tt>whatis</tt> == <!--T:20--> | ||
Line 81: | Line 82: | ||
== Sous-commande <tt>apropos</tt> ou <tt>keyword</tt> == <!--T:21--> | == Sous-commande <tt>apropos</tt> ou <tt>keyword</tt> == <!--T:21--> | ||
Les sous-commandes <tt>apropos</tt> ou <tt>keyword</tt> permettent de chercher un mot-clé dans | Les sous-commandes <tt>apropos</tt> ou <tt>keyword</tt> permettent de chercher un mot-clé dans l'ensemble des modules. Si vous ne savez pas quel module est approprié pour réaliser votre calcul, vous pouvez ainsi chercher dans les descriptions. | ||
= Chargement automatique des modules = <!--T:22--> | = Chargement automatique des modules = <!--T:22--> | ||
Nous vous '''déconseillons de charger des modules automatiquement dans votre .bashrc'''. Nous vous recommandons plutôt de charger les modules | Nous vous '''déconseillons de charger des modules automatiquement dans votre .bashrc'''. Nous vous recommandons plutôt de charger les modules nécessaires au besoin, par exemple dans vos scripts de tâches. Afin de faciliter le chargement d'un grand nombre de modules, il est préférable d'utiliser une collection de modules. | ||
= | = Collection de modules (Lmod seulement) = <!--T:23--> | ||
Lmod vous permet de créer une collection de modules. Pour ce faire, chargez les modules requis | Lmod vous permet de créer une collection de modules. Pour ce faire, chargez d'abord les modules requis avec, par exemple | ||
{{Commande|module load gcc/4.8 openmpi/1.8 mkl}} | {{Commande|module load gcc/4.8 openmpi/1.8 mkl}} | ||
<!--T:24--> | <!--T:24--> | ||
Utilisez ensuite la commande <tt>save</tt> pour sauvegarder cette collection | Utilisez ensuite la commande <tt>save</tt> pour sauvegarder cette collection. | ||
{{Commande|module save mes_modules}} | {{Commande|module save mes_modules}} | ||
L'argument <tt>mes_modules</tt> est un nom que vous donnez à la collection. | L'argument <tt>mes_modules</tt> est un nom que vous donnez à la collection. | ||
Line 103: | Line 104: | ||
= Lmod vs Environment Modules = <!--T:26--> | = Lmod vs Environment Modules = <!--T:26--> | ||
Les principales différences entre l'environnement mis à votre disposition sur les nouveaux serveurs | Les principales différences entre l'environnement mis à votre disposition sur les nouveaux serveurs et les serveurs que vous avez utilisés par le passé sont les suivantes. | ||
== Hiérarchie de modules == <!--T:27--> | == Hiérarchie de modules == <!--T:27--> | ||
La majorité des systèmes utilisent une structure de modules plate | La majorité des systèmes utilisent une structure de modules plate avec tous les modules au même niveau. Ceci devient problématique lorsqu'un grand nombre de combinaisons de versions de différents modules sont disponibles. Par exemple, si vous avez à utiliser la bibliothèque [[FFTW]], et que le module <tt>fftw</tt> est disponible en plusieurs versions, dont une version compilée avec le compilateur <tt>gcc</tt> version 4.8 et <tt>openmpi</tt> 1.6, vous avez peut-être déjà vu des modules nommés <tt>openmpi/1.6_gcc4.8</tt> et <tt>fftw/3.3_gcc4.8_openmpi1.6</tt>. Ceci n'est ni élégant ni pratique. Pour résoudre ce problème, nous utilisons une hiérarchie de modules. Plutôt que d'utiliser la commande | ||
{{Commande|module load gcc/4.8 openmpi/1.6_gcc4.8 fftw/3.3_gcc4.8_openmpi1.6}} | {{Commande|module load gcc/4.8 openmpi/1.6_gcc4.8 fftw/3.3_gcc4.8_openmpi1.6}} | ||
vous utiliserez la commande | vous utiliserez la commande | ||
{{Commande|module load gcc/4.8 openmpi/1.6 fftw/3.3}} | {{Commande|module load gcc/4.8 openmpi/1.6 fftw/3.3}} | ||
Ceci est rendu possible | Ceci est rendu possible avec une hiérarchie de modules. Le module <tt>fftw/3.3</tt> qui est chargé ne sera pas le même si vous avez chargé au préalable le compilateur Intel ou le compilateur GCC. | ||
<!--T:28--> | <!--T:28--> | ||
L'inconvénient d'utiliser une hiérarchie de modules est que, puisque des modules peuvent avoir le même nom, seuls les modules compatibles avec les modules ''parents'' sont affichés par la commande <tt>module avail</tt>. Charger un parent est donc un prérequis afin d'avoir accès à certains modules. Pour avoir l'information complète, Lmod rend disponible la commande <tt>module spider</tt>. Celle-ci | L'inconvénient d'utiliser une hiérarchie de modules est que, puisque des modules peuvent avoir le même nom, seuls les modules compatibles avec les modules ''parents'' sont affichés par la commande <tt>module avail</tt>. Charger un parent est donc un prérequis afin d'avoir accès à certains modules. Pour avoir l'information complète, Lmod rend disponible la commande <tt>module spider</tt>. Celle-ci parcourt la hiérarchie complète et affiche tous les modules. En spécifiant un module et une version particulière, il est alors possible de savoir quels chemins de la hiérarchie permettent de charger le module désiré. | ||
== Collections de modules == <!--T:29--> | == Collections de modules == <!--T:29--> | ||
Les collections de modules sont l'une des fonctionnalités additionnelles fournies par Lmod. Voir [[# | Les collections de modules sont l'une des fonctionnalités additionnelles fournies par Lmod. Voir [[Utiliser des modules#Collections_de_modules_(Lmod_seulement)|cette section]] pour plus de détails. | ||
== Une seule version chargée à la fois == <!--T:30--> | == Une seule version chargée à la fois == <!--T:30--> | ||
Line 122: | Line 123: | ||
== Un seul module d'une même famille chargé à la fois == <!--T:31--> | == Un seul module d'une même famille chargé à la fois == <!--T:31--> | ||
Il est possible pour les administrateurs de spécifier que deux modules portant des noms différents sont de la même famille | Il est possible pour les administrateurs de spécifier que deux modules portant des noms différents sont de la même famille; Lmod refusera alors de les charger. Des exemples typiques seraient les modules de compilateurs (gcc, intel), les modules MPI (openmpi, mvapich2), ou les modules de la bibliothèque BLAS (mkl, openblas). | ||
== Remplacement automatique de modules == <!--T:32--> | == Remplacement automatique de modules == <!--T:32--> | ||
Lorsque Lmod détecte deux modules de la même famille, ou deux versions du même module, la commande <tt>module load</tt> remplacera automatiquement le module original par celui qui doit être chargé. Dans le cas où le module remplacé est un | Lorsque Lmod détecte deux modules de la même famille, ou deux versions du même module, la commande <tt>module load</tt> remplacera automatiquement le module original par celui qui doit être chargé. Dans le cas où le module remplacé est un nœud de la hiérarchie de modules, les modules dépendants seront chargés de nouveau s'il existe une version compatible, ou désactivés dans le cas contraire. | ||
== Modules permanents == <!--T:33--> | == Modules permanents == <!--T:33--> | ||
Lmod permet aux administrateurs de définir un module comme étant permanent (''sticky''). Un tel module ne sera pas enlevé | Lmod permet aux administrateurs de définir un module comme étant permanent (''sticky''). Un tel module ne sera pas enlevé par la commande <tt>module purge</tt>. | ||
= Créer des modules = <!--T:36--> | = Créer des modules = <!--T:36--> | ||
Line 134: | Line 135: | ||
= Utiliser des modules avec ZSH et KSH = <!--T:37--> | = Utiliser des modules avec ZSH et KSH = <!--T:37--> | ||
Si vous voulez utiliser des modules avec les shells ZSH ou KSH, exécutez les commandes suivantes | Si vous voulez utiliser des modules avec les ''shells'' ZSH ou KSH, exécutez les commandes suivantes | ||
{{Command|source $LMOD_PKG/init/zsh}} | {{Command|source $LMOD_PKG/init/zsh}} | ||
{{Command|source $LMOD_PKG/init/ksh}} | {{Command|source $LMOD_PKG/init/ksh}} | ||
</translate> | </translate> |