Skip to main content

Utiliser les modules d'environnement

Les logiciels disponibles sur eXplor-v2 sont principalement gérés avec des modules d'environnement. Un module configure temporairement votre shell pour rendre un logiciel, une bibliothèque ou un compilateur accessible.

Le chargement d'un module peut notamment modifier :

  • PATH, pour rendre un exécutable disponible ;
  • LD_LIBRARY_PATH, pour rendre des bibliothèques partagées accessibles ;
  • MANPATH, pour rendre la documentation disponible ;
  • CPATH, LIBRARY_PATH ou PKG_CONFIG_PATH, pour la compilation ;
  • des variables propres au logiciel, comme CUDA_HOME ou MPI_HOME.
Pourquoi utiliser des modules ?

Les modules permettent à plusieurs versions d'un même logiciel de coexister. Ils évitent de modifier manuellement les variables d'environnement et facilitent la reproduction d'un environnement dans un job SLURM.

Commandes essentielles​

CommandeRôle
module availAfficher les modules disponibles
module spider <nom>Rechercher un module, lorsque cette commande est disponible
module keyword <mot>Rechercher par mot-clé, lorsque cette commande est disponible
module load <module>Charger un module
module listAfficher les modules chargés
module unload <module>Décharger un module
module purgeDécharger tous les modules
module show <module>Afficher les modifications apportées par un module
module help <module>Afficher l'aide d'un module

La liste et les commandes disponibles peuvent dépendre de la configuration locale du gestionnaire de modules.

Rechercher un logiciel​

Commencez par afficher les modules visibles :

module avail

Recherchez un logiciel par son nom :

module spider <logiciel>

Exemple générique :

module spider python

Si module spider n'est pas disponible, utilisez :

module avail 2>&1 | grep -i python

Vous pouvez également essayer :

module keyword python
Nom et version

Le nom d'un module dépend de la configuration du centre. Une version peut apparaître sous une forme comme logiciel/1.2.3, mais vous devez toujours utiliser le nom exact retourné par les commandes de recherche.

Charger un module​

Chargez un module avec :

module load <module>

Exemple générique :

module load <logiciel>/<version>

Vérifiez les modules chargés :

module list

Vérifiez ensuite que l'exécutable correspond à la version attendue :

which <executable>
<executable> --version

Exemple de séquence :

module purge
module load <module>
module list
which <executable>

Choisir une version​

Lorsqu'un logiciel existe dans plusieurs versions, chargez explicitement celle dont votre projet a besoin :

module load <logiciel>/<version>

Évitez de dépendre d'une version par défaut si la reproductibilité est importante. Notez la version dans :

  • le script SLURM ;
  • la documentation du projet ;
  • un fichier de configuration ;
  • les logs produits par le job.

Pour connaître les versions chargées :

module list

Décharger et réinitialiser​

Déchargez un module :

module unload <module>

Pour repartir d'un environnement propre :

module purge

Puis chargez explicitement les modules nécessaires :

module purge
module load <module-1>
module load <module-2>
module list
Éviter les environnements hérités

Un terminal peut déjà contenir des modules chargés automatiquement ou lors d'un travail précédent. Dans un script batch de production, commencez généralement par module purge, puis chargez explicitement l'environnement requis.

Comprendre un module​

Pour afficher les changements appliqués par un module :

module show <module>

Cette commande peut notamment afficher :

  • les chemins ajoutés à PATH ;
  • les bibliothèques ajoutées à LD_LIBRARY_PATH ;
  • les dépendances chargées automatiquement ;
  • les variables spécifiques au logiciel ;
  • les conflits avec d'autres modules.

Pour obtenir l'aide associée :

module help <module>

Modules et dépendances​

Certains modules dépendent d'un compilateur, d'une version MPI ou d'une bibliothèque spécifique. Le chargement d'un module peut alors charger automatiquement d'autres modules ou nécessiter un environnement particulier.

Exemple de préparation générique :

module purge
module load <compilateur>
module load <mpi>
module load <application>
module list

Lorsque vous compilez ou exécutez un code parallèle, utilisez un ensemble cohérent de compilateur, MPI et bibliothèques. Consultez Compilateurs et MPI.

Modules dans un job SLURM​

Chargez toujours les modules dans le script soumis à Slurm. Ne supposez pas que le job héritera de la configuration du shell depuis lequel vous avez lancé sbatch.

Exemple :

#!/bin/bash
#SBATCH --job-name=mon-calcul
#SBATCH --partition=std
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=01:00:00
#SBATCH --output=logs/%x-%j.out
#SBATCH --error=logs/%x-%j.err

set -euo pipefail

mkdir -p logs

module purge
module load <module>
module list

which <executable>
<executable> --version

<executable> <arguments>

L'ajout de module list, which et --version dans les logs permet de vérifier l'environnement réellement utilisé par le job.

Modules dans une session interactive​

Dans une session interactive, vous pouvez charger des modules pour tester un logiciel :

module purge
module load <module>
module list

Une fois l'environnement validé, reportez les mêmes commandes dans votre script batch.

Consultez Jobs interactifs.

Conflits et problèmes courants​

Module introuvable​

Vérifiez le nom et la version :

module spider <logiciel>
module avail

Le module peut nécessiter le chargement préalable d'un compilateur, d'une pile logicielle ou d'un module parent.

Commande introuvable après module load​

Vérifiez :

module list
module show <module>
which <executable>
echo "$PATH"

Le nom du module et le nom de l'exécutable peuvent être différents.

Conflit entre modules​

Commencez par nettoyer l'environnement :

module purge

Puis chargez les modules dans l'ordre recommandé. Consultez module show ou module help pour identifier les dépendances et les conflits.

Mauvaise version utilisée​

Vérifiez :

module list
which <executable>
<executable> --version

Chargez explicitement la version requise et évitez les versions par défaut dans les workflows de production.

Bibliothèque introuvable à l'exécution​

Le programme peut avoir été compilé avec un compilateur ou une bibliothèque différente de ceux actuellement chargés. Rechargez l'environnement de compilation cohérent ou recompilez le programme dans l'environnement prévu.

Bonnes pratiques​

  • Commencez un script de production par module purge.
  • Chargez explicitement les modules et leurs versions.
  • Vérifiez les modules actifs avec module list.
  • Vérifiez les exécutables avec which et --version.
  • Utilisez le même compilateur et la même pile MPI pour compiler et exécuter un programme parallèle.
  • Ajoutez module list dans les logs des calculs importants.
  • Évitez de modifier manuellement PATH ou LD_LIBRARY_PATH lorsque le module correspondant existe.
  • Testez l'environnement dans une session interactive avant une campagne batch.
  • Conservez les modules et versions dans les scripts versionnés.

Pages associées​