Environnements logiciels

Un environnement logiciel définit les outils, bibliothèques et variables disponibles lorsqu'une commande est exécutée. Sur eXplor-v2, il est principalement construit avec les modules d'environnement, puis complété si nécessaire par un environnement de projet, tel qu'un environnement Python ou un conteneur Apptainer.

Cette page traite de l'environnement général du système : compilateurs, bibliothèques, variables, chemins de recherche et contexte d'exécution. Pour les environnements spécifiques à Python, consultez Python et Conda.

Pourquoi l'environnement est important

Deux sessions peuvent exécuter la même commande avec un résultat différent si elles ne chargent pas :

la même version de logiciel ;
le même compilateur ;
la même bibliothèque MPI ;
les mêmes bibliothèques partagées ;
les mêmes variables d'environnement ;
le même environnement Python ou conteneur.

Un environnement explicitement défini améliore la reproductibilité et réduit les erreurs difficiles à diagnostiquer.

Les éléments d'un environnement

Élément	Rôle	Commande de vérification
Modules chargés	Logiciels, compilateurs et bibliothèques disponibles	`module list`
`PATH`	Répertoires recherchés pour les exécutables	`echo "$PATH"`
`LD_LIBRARY_PATH`	Répertoires recherchés pour les bibliothèques partagées	`echo "$LD_LIBRARY_PATH"`
`CPATH`	Répertoires d'en-têtes utilisés à la compilation	`echo "$CPATH"`
`LIBRARY_PATH`	Répertoires de bibliothèques utilisés à la compilation	`echo "$LIBRARY_PATH"`
`PKG_CONFIG_PATH`	Fichiers de configuration des bibliothèques	`echo "$PKG_CONFIG_PATH"`
Variables du logiciel	Chemins ou paramètres propres à un outil	`env \| grep -i nom_du_logiciel`
Environnement Python	Interpréteur et paquets Python actifs	`which python`
Conteneur	Image et montages utilisés par Apptainer	Commande Apptainer du job

Examiner l'environnement actuel

Modules chargés

module list

Variables importantes

echo "PATH=$PATH"
echo "LD_LIBRARY_PATH=${LD_LIBRARY_PATH:-non défini}"
echo "CPATH=${CPATH:-non défini}"
echo "LIBRARY_PATH=${LIBRARY_PATH:-non défini}"
echo "PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-non défini}"

Toutes les variables

env | sort

Pour filtrer une variable ou un groupe de variables :

env | grep -i cuda
env | grep -i mpi
env | grep -i python

Exécutables réellement utilisés

which nom_executable
type -a nom_executable
readlink -f "$(command -v nom_executable)"

Remplacez nom_executable par la commande concernée, par exemple un compilateur, python, mpirun ou une application scientifique.

Bibliothèques utilisées

Sur un exécutable Linux, vous pouvez afficher les bibliothèques dynamiques référencées :

ldd ./mon-programme

Interpréter ldd avec prudence

Utilisez ldd uniquement sur des exécutables de confiance. Cette commande est utile pour comprendre les dépendances d'un programme, mais elle ne remplace pas la documentation de l'application ou de son environnement de compilation.

Construire un environnement propre

Dans une nouvelle session ou un script Slurm, commencez généralement par supprimer les modules précédemment chargés :

module purge

Chargez ensuite les composants nécessaires, dans un ordre cohérent :

module purge
module load nom_compilateur
module load nom_mpi
module load nom_application
module list

Vérifiez les outils utilisés :

which nom_executable
nom_executable --version

Modules et ordre de chargement

Certains modules chargent automatiquement leurs dépendances. D'autres nécessitent un compilateur ou une pile MPI précise. Utilisez module show nom_module et module help nom_module pour comprendre l'environnement attendu.

Nœud de connexion et nœud de calcul

Un environnement ouvert sur un nœud de connexion n'est pas nécessairement identique à celui d'un nœud de calcul.

Les différences possibles incluent :

le type de processeur ;
la présence d'un GPU ;
les pilotes GPU ;
les bibliothèques disponibles ;
les variables définies par Slurm ;
les chemins temporaires locaux.

Testez l'environnement qui sera réellement utilisé avec une allocation interactive CPU :

salloc \
  --partition=std \
  --ntasks=1 \
  --cpus-per-task=2 \
  --mem=4G \
  --time=00:15:00

srun --pty bash

Dans la session, vérifiez :

hostname
module list
which nom_executable
nom_executable --version

Tester un environnement GPU en session interactive

Avant une campagne batch GPU, validez CUDA, les modules, la mémoire GPU disponible et votre application dans une allocation interactive sur la partition gpu.

Depuis SSH, démarrez une allocation interactive puis ouvrez un shell sur le nœud GPU attribué :

salloc \
  --partition=gpu \
  --ntasks=1 \
  --cpus-per-task=4 \
  --mem=16G \
  --gres=gpu:1 \
  --time=01:00:00

srun --pty bash

Utilisez la syntaxe officiellement retenue sur eXplor-v2. Une fois dans l'allocation, vérifiez le nœud et l'accélérateur :

hostname
nvidia-smi
nvidia-smi --query-gpu=name,memory.total --format=csv

Chargez ensuite les modules requis et réalisez un test court :

module purge
module load nom_module_cuda
module load nom_application
module list

./mon-programme --test

Utilisez le GPU dans l'allocation

N'exécutez aucun calcul GPU sur le nœud de connexion. Les tests et traitements GPU doivent être effectués exclusivement sur un nœud GPU attribué par Slurm.

Après validation, reportez les mêmes modules, versions et ressources dans le script batch de production.

Consultez également Jobs interactifs, Ressources et partitions Slurm et CUDA et GPU.

Environnement et job Slurm

Un script batch doit définir explicitement son environnement. Ne dépendez pas des modules ou variables chargés dans votre terminal avant l'exécution de 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 nom_compilateur
module load nom_application

module list
which nom_executable
nom_executable --version

nom_executable arguments

L'enregistrement de module list, des chemins et des versions dans les fichiers de sortie permet de retrouver l'environnement exact en cas de problème ou de relance du calcul.

Variables Slurm

Dans une allocation Slurm, certaines variables fournissent des informations sur les ressources attribuées :

echo "Job ID: ${SLURM_JOB_ID:-non défini}"
echo "Nœuds: ${SLURM_JOB_NODELIST:-non défini}"
echo "CPU par tâche: ${SLURM_CPUS_PER_TASK:-non défini}"
echo "Tâches: ${SLURM_NTASKS:-non défini}"
echo "Répertoire de soumission: ${SLURM_SUBMIT_DIR:-non défini}"

Elles peuvent être utilisées dans les scripts pour adapter une commande aux ressources réellement attribuées.

Exemple OpenMP :

export OMP_NUM_THREADS="${SLURM_CPUS_PER_TASK:-1}"

Éviter les conflits

Les conflits les plus fréquents sont liés à :

plusieurs compilateurs chargés simultanément ;
plusieurs implémentations MPI incompatibles ;
une bibliothèque trouvée dans un mauvais ordre ;
un environnement Conda qui masque les exécutables fournis par les modules ;
des variables PATH ou LD_LIBRARY_PATH modifiées manuellement ;
un binaire compilé dans un environnement différent de celui utilisé à l'exécution.

En cas de problème :

module purge
module list
env | sort
which nom_executable

Rechargez ensuite uniquement les modules nécessaires et vérifiez les versions avant de relancer le programme.

Modules, Python et conteneurs

Les environnements de projet complètent l'environnement système :

les modules sélectionnent la pile logicielle générale ;
venv, Conda ou Micromamba isolent les dépendances Python d'un projet ;
Apptainer encapsule un logiciel et ses dépendances dans une image ;
Slurm attribue les ressources nécessaires à l'exécution.

Exemple d'ordre de préparation pour un projet Python avec un module :

module purge
module load nom_module_python
source "$HOME/mon-projet/.venv/bin/activate"

which python
python --version
python -m pip list

Consultez :

Capturer l'environnement

Pour faciliter la reproductibilité, enregistrez les informations suivantes dans les logs ou dans un fichier dédié :

module list 2>&1
env | sort
which nom_executable
nom_executable --version

Vous pouvez enregistrer ces informations avant le calcul :

{
  echo "=== Modules ==="
  module list 2>&1
  echo "=== Environnement ==="
  env | sort
  echo "=== Date ==="
  date --iso-8601=seconds
} > environment-${SLURM_JOB_ID:-local}.txt

Évitez d'archiver ou de publier des variables contenant des secrets, jetons ou mots de passe.

Bonnes pratiques

Commencez les scripts batch avec module purge.
Chargez explicitement les modules et leurs versions.
Utilisez le même environnement pour compiler et exécuter un programme lorsque cela est nécessaire.
Vérifiez l'exécutable réellement lancé avec which ou command -v.
Vérifiez les versions avec --version.
Testez l'environnement sur un nœud de calcul avant la production.
Validez les modules CUDA, la mémoire GPU et votre logiciel dans une allocation interactive avant une campagne batch GPU.
Isolez les dépendances Python dans un environnement de projet.
Utilisez un conteneur lorsque l'environnement est trop complexe ou difficile à reproduire.
N'ajoutez pas durablement des chemins au hasard dans PATH ou LD_LIBRARY_PATH.
Enregistrez modules, versions et paramètres dans les logs des calculs importants.

Pourquoi l'environnement est important​

Les éléments d'un environnement​

Examiner l'environnement actuel​

Modules chargés​

Variables importantes​

Toutes les variables​

Exécutables réellement utilisés​

Bibliothèques utilisées​

Construire un environnement propre​

Nœud de connexion et nœud de calcul​

Tester un environnement GPU en session interactive​

Environnement et job Slurm​

Variables Slurm​

Éviter les conflits​

Modules, Python et conteneurs​

Capturer l'environnement​

Bonnes pratiques​

Pages associées​