Skip to main content

Reproductibilité des calculs

La reproductibilité scientifique est la capacité à obtenir les mêmes résultats en réexécutant une analyse avec les mêmes données, le même code et le même environnement logiciel. Sur un supercalculateur comme eXplor-v2, plusieurs facteurs peuvent affecter la reproductibilité :

  • les versions des compilateurs, des bibliothèques et des applications ;
  • les environnements logiciels (modules, Conda, conteneurs) ;
  • les bibliothèques mathématiques (BLAS, LAPACK, FFTW, etc.) ;
  • le parallélisme (MPI, OpenMP, GPU) et les paramètres d’exécution ;
  • les optimisations du compilateur et les instructions CPU ciblées.

Cette page présente les bonnes pratiques pour maximiser la reproductibilité de vos calculs sur eXplor-v2.

Principes généraux​

1. Documenter l’environnement logiciel​

Pour chaque campagne de calcul, notez précisément :

  • les modules chargés (module list) ;
  • les versions des compilateurs (gcc --version, nvcc --version, etc.) ;
  • les versions des bibliothèques clés (BLAS, LAPACK, MPI, CUDA, etc.) ;
  • les versions des applications et des scripts utilisés ;
  • les options de compilation et d’optimisation.

Exemple de journal minimal :

# Date : 2025-08-25
# Projet : simulation-turbulence
# Commit Git : a3f5c9d

module list

# Compilateurs
gcc --version
nvcc --version

# Bibliothèque MPI
mpirun --version

# Bibliothèques mathématiques
ldd ./mon-executable | grep -E 'blas|lapack|fftw'

# Options de compilation
echo "CFLAGS: -O3 -march=native -ffast-math"
echo "LDFLAGS: -lblas -llapack"

2. Figer les versions des logiciels​

Évitez de laisser les versions implicites ou « à jour ». Préférez :

  • charger explicitement les modules avec leur version : module load gcc/13.2.0 plutôt que module load gcc ;
  • utiliser des environnements Conda décrits dans un fichier environment.yml versionné ;
  • utiliser des conteneurs Apptainer avec une image .sif figée et documentée.

3. Versionner le code et les scripts​

Utilisez un système de gestion de versions (Git, SVN) pour :

  • le code source ;
  • les scripts de compilation ;
  • les scripts de soumission Slurm ;
  • les fichiers de configuration ;
  • la documentation des environnements.

Exemple de structure minimale :

mon-projet/
├── src/                  # code source
├── scripts/              # scripts de compilation et de soumission
├── config/               # fichiers de configuration
├── environment.yml       # environnement Conda (si applicable)
├── container.def         # fichier de définition Apptainer (si applicable)
├── README.md             # documentation
└── logs/                 # journaux d’exécution

4. Archiver les résultats et les journaux​

Conservez :

  • les fichiers de sortie et d’erreur des jobs Slurm ;
  • les journaux de compilation ;
  • les versions exactes des données d’entrée ;
  • un récapitulatif des ressources Slurm utilisées (partition, nombre de cœurs, GPU, mémoire, durée).

Outils pour la reproductibilité​

Modules environnementaux​

Les modules permettent de charger des versions spécifiques de logiciels. Pour figer un environnement :

module purge
module load gcc/13.2.0
module load openmpi/4.1.5
module load cuda/12.4.0
module save projet-simulation

Puis, dans les scripts Slurm :

module restore projet-simulation
Limites des modules

Les modules figent les versions des logiciels, mais pas nécessairement toutes les dépendances système. Pour une reproductibilité maximale, combinez les modules avec d’autres outils, tels que Conda ou Apptainer.

Environnements Conda​

Conda permet de créer des environnements Python et d’autres langages, isolés et reproductibles.

  1. Créez un fichier environment.yml :
name: mon-environnement
channels:
  - conda-forge
  - defaults
dependencies:
  - python=3.11
  - numpy=1.26.4
  - scipy=1.13.0
  - matplotlib=3.8.4
  - pip
  - pip:
      - torch==2.3.0
  1. Créez l’environnement :
conda env create -f environment.yml
  1. Activez-le dans les scripts :
source "$HOME/.conda/envs/mon-environnement/bin/activate"
  1. Versionnez le fichier environment.yml dans Git.

Conteneurs Apptainer​

Les conteneurs offrent un niveau élevé de reproductibilité en encapsulant l’environnement logiciel nécessaire à l’exécution.

  1. Créez ou récupérez une image :
apptainer build mon-image.sif docker://ubuntu:22.04

  1. Testez l’image dans une allocation interactive.

  2. Utilisez-la dans les scripts Slurm :

apptainer exec mon-image.sif ma-commande
  1. Archivez l’image .sif et le fichier de définition, le cas échéant.
Reproductibilité maximale

Pour une reproductibilité maximale, privilégiez les conteneurs Apptainer. Ils regroupent les bibliothèques et les applications nécessaires dans un fichier .sif. Ils ne remplacent toutefois pas complètement l’environnement matériel, le pilote GPU ou le noyau du système hôte.

Facteurs affectant la reproductibilité​

Optimisations du compilateur​

Certaines options d’optimisation peuvent affecter la reproductibilité numérique :

  • -O3, -Ofast, -ffast-math : peuvent modifier l’ordre des opérations flottantes ;
  • -march=native : optimise pour le CPU hôte, mais peut rendre le binaire non portable ;
  • -funroll-loops, -fpredictive-commoning : peuvent affecter la précision.

Pour une reproductibilité numérique stricte :

gcc -O2 -march=x86-64 -fno-fast-math -fno-associative-math ...

Bibliothèques mathématiques​

Les bibliothèques comme BLAS, LAPACK, FFTW, MKL et cuBLAS peuvent avoir :

  • plusieurs implémentations (OpenBLAS, MKL, BLIS, etc.) ;
  • plusieurs versions avec des comportements numériques légèrement différents ;
  • des paramètres d’exécution (nombre de threads, taille de bloc, etc.).

Figez :

  • l’implémentation et la version ;
  • les variables d’environnement, par exemple OMP_NUM_THREADS et MKL_NUM_THREADS ;
  • les paramètres de performance.

Parallélisme (MPI, OpenMP, GPU)​

Le parallélisme peut introduire des variations :

  • MPI : l’ordre des réceptions peut varier selon le nombre de processus et la topologie ;
  • OpenMP : l’ordre des opérations peut varier selon le nombre de threads ;
  • GPU : les opérations flottantes sur GPU ne sont pas toujours déterministes.

Pour minimiser les variations :

  • figez le nombre de processus MPI et de threads OpenMP ;
  • utilisez des graines aléatoires fixes pour les générateurs de nombres aléatoires ;
  • testez la sensibilité de vos résultats à ces variations.

Versions CUDA et GPU​

Les calculs GPU peuvent varier selon :

  • la version du pilote NVIDIA ;
  • la version de CUDA et des bibliothèques associées (cuBLAS, cuDNN, etc.) ;
  • le modèle de GPU (V100, A100, H100, etc.).

Figez :

  • la version de CUDA ;
  • le modèle de GPU, en utilisant les partitions Slurm appropriées ;
  • les bibliothèques GPU utilisées.

Checklist de reproductibilité​

Avant une campagne de production, vérifiez :

  • les versions des modules sont explicitement spécifiées ;
  • le code et les scripts sont versionnés avec Git ;
  • les options de compilation sont documentées ;
  • les bibliothèques clés (MPI, BLAS, CUDA, etc.) sont identifiées ;
  • les paramètres d’exécution (MPI, OpenMP, GPU) sont figés ;
  • un environnement reproductible est mis en place (modules, Conda, Apptainer) ;
  • les journaux de compilation et d’exécution sont archivés ;
  • les données d’entrée sont versionnées ou archivées ;
  • un fichier README ou MANIFEST décrit l’environnement complet.

Pages associées​