Reading Time: 11 minutes

Les flux de travail de recherche reproductibles garantissent que les résultats de la simulation peuvent être exactement recréés par les autres (ou votre futur moi) en utilisant les mêmes données, codes et environnement de calcul. Docker fournit une conteneurisation complète au niveau du système pour une cohérence maximale entre les plates-formes, tandis que CONDA offre un package léger et une gestion de l’environnement idéal pour le calcul scientifique basé sur Python. Pour les projets de simulation, nous recommandons : (1) utiliser CONDA pour le développement quotidien et la gestion des dépendances, (2) créer des images Docker pour « geler » les environnements de travail pour la publication et la collaboration, et (3) toujours associer au contrôle de version et à une documentation approfondie. Évitez l’erreur courante de se fier uniquement à un seul outil : combinez les deux pour une reproductibilité robuste.

Introduction : L’écart de reproductibilité dans la recherche en simulation

Les projets de simulation scientifique souffrent souvent d’un mode de défaillance silencieux : le code a fonctionné hier, mais aujourd’hui, il produit des résultats différents. La physique sous-jacente n’a pas changé, votre environnement de calcul l’a fait. Les versions de packages manquantes, les dépendances de bibliothèque modifiées, les mises à jour du système d’exploitation ou même différents interpréteurs Python peuvent modifier silencieusement les sorties de simulation, parfois de manière difficile à détecter.

C’est plus qu’un inconvénient. Reproductibilité est la pierre angulaire de la science cumulative, la capacité pour d’autres chercheurs à vérifier les réclamations et à s’appuyer sur votre travail. Lorsque les résultats de la simulation ne peuvent pas être recréés de manière fiable, les érodes de confiance, les articles sont rétractés et un temps de recherche précieux est perdu à déboguer les problèmes environnementaux au lieu de faire progresser les connaissances.

Dans ce guide, nous examinerons comment mettre en œuvre des flux de recherche reproductibles pour des projets de simulation à l’aide de Docker et CONDA : deux outils complémentaires qui, lorsqu’ils sont utilisés ensemble, fournissent une solution robuste pour la cohérence de l’environnement, la gestion des dépendances et la conservation à long terme de Méthodes informatiques.

Qu’est-ce que la recherche reproductible ? Définitions et composants de base

À la base, recherche reproductible signifie qu’un chercheur indépendant peut régénérer les résultats publiés (tableaux, chiffres, résultats quantitatifs) en utilisant uniquement les données, le code et la documentation d’origine. Tel que défini par Turing Way et largement adopté en sciences informatiques, cela nécessite :

  • Données de données : les données d’entrée brutes sont accessibles (avec des considérations de confidentialité appropriées)
  • Transparence du code : tous les scripts d’analyse et de simulation sont partagés
  • Documentation : enregistrements complets des versions du logiciel, des paramètres et des configurations d’environnement
  • Compute Environmental Control : l’environnement d’exécution exact est capturé et reconstruit

La reproductibilité informatique diffère de la replicabilité (obtenant des conclusions similaires à l’aide de nouvelles données ou de méthodes indépendantes). La reproductibilité est la norme minimale : il s’agit d’obtenir les mêmes chiffres des mêmes entrées, et non de valider les affirmations scientifiques sous-jacentes.

Pourquoi c’est important pour les projets de simulation : les solveurs PDE, les méthodes par éléments finis et d’autres cadres de simulation impliquent souvent des chaînes de dépendance complexes. Un changement de version mineur dans une bibliothèque numérique peut modifier le comportement de discrétisation, les critères de convergence ou l’arrondi, en produisant des résultats mesurablement différents. Les flux de travail reproductibles éliminent cette source d’incertitude.

Docker pour des simulations scientifiques reproductibles

Ce que Docker fournit

Docker est une plate-forme de conteneurisation qui regroupe une application et l’ensemble de son environnement d’exécution (système d’exploitation, bibliothèques, dépendances, fichiers de configuration) dans une image portable et immuable. Lorsque vous exécutez un conteneur Docker, vous exécutez exactement le même environnement qui a été construit et testé, quel que soit le système hôte.

Pour les projets de simulation, Docker propose :

  1. Cohérence environnementale : plus « ça marche sur ma machine ». Le conteneur comprend des versions spécifiques des compilateurs, des implémentations MPI, des interpréteurs Python et des bibliothèques numériques.
  2. Portabilité de la plate-forme : une image Docker construite sur un ordinateur portable peut fonctionner sur un cluster HPC, une instance cloud ou un poste de travail de collègue sans modification.
  3. isolement : les dépendances de simulation n’entrent pas en conflit avec les bibliothèques système ou d’autres projets.
  4. Snapshots versionnés : chaque image Docker est immuable et peut être étiquetée (par exemple, my-sim:paper-v1) pour une reproduction exacte future.

Limites de Docker à prendre en compte

Malgré ses atouts, Docker a des contraintes importantes pour le calcul scientifique :

  • Pas une solution miracle : comme indiqué dans « Docker ne garantit pas la reproductibilité » (ARXIV 2026), les conteneurs peuvent toujours présenter un comportement non déterministe si le matériel sous-jacent diffère (architecture CPU, optimisations en virgule flottante) ou si les services externes (base de données, fichier système) varient.
  • Dépendance du noyau : les conteneurs Docker partagent le noyau hôte. Cela signifie que le comportement du conteneur peut toujours être affecté par la version et la configuration du noyau hôte.
  • Size Overhead : les images complètes du système d’exploitation peuvent être grandes (des centaines de Mo à GB), bien que des images minces comme alpine aident.
  • Restrictions HPC : de nombreux centres HPC n’autorisent pas Docker directement en raison de problèmes de sécurité ; Ils utilisent plutôt singularité ou apptainer. Cependant, vous pouvez créer des images de singularité à partir d’images Docker, faisant de Docker un outil de développement viable.

Rédaction de Dockerfiles pour des projets de simulation

Le Dockerfile définit comment créer votre conteneur. À la suite de « Dix règles simples pour la rédaction de Dockerfiles for Reproductible Research » (Nüst et al., 2020), les principales pratiques comprennent:

# Start from a minimal, pinned base image
FROM ubuntu:22.04  # Pin exact version, not :latest

# Set environment variables for reproducibility
ENV LANG=C.UTF-8
ENV LC_ALL=C.UTF-8

# Install system dependencies in one layer to minimize cache issues
RUN apt-get update && apt-get install -y 
    python3 
    python3-pip 
    libopenblas-dev 
    && rm -rf /var/lib/apt/lists/*

# Create and set working directory
WORKDIR /simulation

# Copy dependency specifications first (for better caching)
COPY requirements.txt environment.yml ./

# Install Python packages with pinned versions
RUN pip install --no-cache-dir -r requirements.txt

# Copy simulation code
COPY src/ ./src/
COPY scripts/ ./scripts/
COPY data/ ./data/

# Define entry point or command
ENTRYPOINT ["python3", "scripts/run_simulation.py"]

Règle de clé : épinglez toutes les versions de manière explicite : image de base, packages de système d’exploitation, packages Python et même version PIP. Utilisez requirements.txt ou environment.yml avec des versions exactes (package==1.2.3, pas package>=1.0).

Conda pour la gestion de l’environnement dans la recherche

Ce que Conda fournit

CONDA est un gestionnaire de packages et d’environnements multi-plateforme qui gère non seulement les packages Python, mais également les dépendances non Python (bibliothèques C/C++, compilateurs, MPI). Cela le rend particulièrement bien adapté à la simulation scientifique où vous pourriez avoir besoin de versions spécifiques d’OpenMPI, FFTW ou HDF5.

Conda livre :

  1. Agnostique linguistique : installez les bibliothèques Python, R, C/C++ et les outils système dans un seul environnement.
  2. Dépendances binaires : les packages pré-compilés évitent la compilation de l’enfer sur différents systèmes.
  3. Environnements isolés : chaque projet a son propre environnement sans contamination croisée.
  4. export/import : conda env export > environment.yml Capture l’ensemble de l’environnement pour une reproduction exacte.

Meilleures pratiques Conda

Basé sur les conseils de MSI University of Minnesota et Anaconda :

  • Ne jamais installer dans base : créer un nouvel environnement pour chaque projet : 
    conda create --name my-simulation python=3.11
conda activate my-simulation
  • Utiliser les canaux communautaires : préfère conda-forge aux valeurs par défaut pour des packages scientifiques plus à jour : 
    conda config --add channels conda-forge
conda config --set channel_priority strict
  • Installer tous les packages à la fois : cela évite les conflits de dépendance : 
    conda install numpy scipy matplotlib fipy
  • Ne modifiez pas les environnements existants : si vous avez besoin de nouveaux packages, mettez à jour la spécification de l’environnement ou créez un nouvel environnement à partir du fichier YAML mis à jour.
  • Exporter proprement  : lors du partage, supprimez les packages spécifiques à la plate-forme et les éléments installés par PIP qui ne sont pas essentiels : 
    conda env export --no-builds | grep -v "prefix:" > environment.yml

Docker vs Conda : quand choisir lequel

La question n’est pas « Docker ou Conda ? » : ils résolvent différents problèmes et sont complémentaires.

aspect Docker peste
Scope Système d’exploitation et d’exécution complets Forfait & Responsable environnement
Isolation Niveau système (espace de noms du noyau) Environnement d’espace utilisateur
Taille Grand (100 Mo–1 Go+) Petit (Mbs)
Vitesse Plus lent à construire/transférer Activation instantanée
Assistance HPC Limité (travaux de singularité) Excellent (natif)
Cas d’utilisation Publication, partage, déploiement Développement quotidien, exploration

Recommandation pratique

  • Utilisez Conda pour le développement : créez rapidement des environnements isolés, testez des dépendances, itérez sur le code. C’est léger et rapide.
  • Utilisez Docker pour la conservation : une fois que votre simulation fonctionne, créez une image Docker pour « geler » l’environnement exact. Partagez cette image avec des collaborateurs, joignez-la à des publications ou utilisez-la pour CI/CD.
  • Combinez les deux : développez en conda, puis créez un fichier Docker qui :
    • copie l’environnement conda dans l’image, soit
    • recrée l’environnement à l’aide de l’export environment.yml

Cette approche en couches vous donne une agilité de développement et une robustesse de publication.

Intégration de Docker et Conda dans les flux de travail scientifiques

Stratégie 1 : Conda à l’intérieur de Docker

L’intégration la plus courante consiste à installer et à utiliser Conda dans un conteneur Docker. Cela vous donne la gestion de packages à grain fin de Conda dans l’isolation du système de Docker.

FROM ubuntu:22.04

# Install Miniconda
RUN wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh 
    && bash Miniconda3-latest-Linux-x86_64.sh -b -p /opt/conda 
    && rm Miniconda3-latest-Linux-x86_64.sh
ENV PATH=/opt/conda/bin:$PATH

# Create and use a conda environment
COPY environment.yml .
RUN conda env create -f environment.yml
ENV PATH=/opt/conda/envs/my-sim/bin:$PATH

Pros : exploite l’écosystème de packages scientifiques étendu de Conda ; Conformément aux workflows de développement local.
Cons : taille d’image plus grande ; Nuances d’activation de Conda dans Docker.

Stratégie 2 : Docker pour la capture d’environnement

Développez localement avec Conda, puis exportez l’environnement et cuisez-le dans une image Docker sans exécuter Conda au moment de l’exécution :

FROM python:3.11-slim

# Copy pre-built packages or use pip from a frozen requirements.txt
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

Ceci est plus simple mais perd la gestion des dépendances non-Python de Conda.

Stratégie 3 : builds en plusieurs étapes pour HPC

Pour les clusters HPC utilisant Singularity, créez l’image Docker localement, puis convertissez-vous en Singularity :

docker build -t my-sim:latest .
singularity build my-sim.sif docker://my-sim:latest

Ce flux de travail vous permet de développer avec Docker (test facile) et de déployer sur HPC (Singularity).

Des pièges courants et comment les éviter

Sur la base de l’analyse des défis de la reproductibilité dans la recherche par simulation, voici des erreurs critiques à éviter :

1. Documentation manquante ou incomplète

Problème : vous avez une image Docker en état de marche, mais aucune trace de la façon de l’utiliser, des entrées qu’elle attend ou de la manière d’interpréter les sorties.

Solution : inclure un README.md dans le conteneur (ou à côté de l’image) avec :

  • Comment exécuter la simulation (arguments de ligne de commande)
  • Formats de fichiers d’entrée attendus
  • Descriptions des fichiers de sortie
  • Besoin matériel (CPU, mémoire, GPU)
  • Limites connues

2. Dépendances non épinglées

Problème : Utilisation de numpy>=1.0 ou python=3.x Autorise les mises à jour automatiques qui peuvent changer de comportement.

Solution : broches exactes des versions environment.yml et requirements.txt :

dependencies:
  - python=3.11.8
  - numpy=1.26.4
  - scipy=1.11.4
  - pip:
    - my-package==0.3.2

3. Simulations non déterministes

Problème : même avec des environnements identiques, les simulations produisent des résultats légèrement différents en raison de la non-associativité à virgule flottante, des conditions de course parallèles ou de la mémoire non initialisée.

Solution :

  • Définir des drapeaux déterministes le cas échéant (par exemple, OpenMP OMP_NUM_THREADS=1, threading BLAS)
  • Utilisez des graines aléatoires fixes et documentez-les
  • Testez la reproductibilité en exécutant le conteneur plusieurs fois sur le même hôte

4. Grands données à l’intérieur des conteneurs

Problème : la préparation de grands ensembles de données de simulation dans les images Docker les gonfle et ralentit la distribution.

Solution : gardez les données externes. Utilisez des volumes Docker ou des montages de liaison pour joindre des données au moment de l’exécution :

docker run -v /path/to/data:/data my-sim:latest

Documenter clairement les attentes.

5. Ignorer les contraintes HPC

Problème : les images Docker qui fonctionnent sur un ordinateur portable tombent en panne sur un cluster HPC en raison de l’implémentation MPI manquante, des pilotes incompatibles ou des restrictions de sécurité.

Solution :

  • Testez tôt dans un environnement de type cluster
  • Utilisez la compatibilité avec la singularité lors du ciblage de HPC
  • Évitez les modèles Docker-In-Docker ; Construisez sur une image de base qui correspond au système d’exploitation du cluster (par exemple, CentOS/Rocky si le cluster les utilise)

6. Aucun contrôle de version pour les fichiers Docker et les fichiers d’environnement

Problème : vous avez une image de travail mais pas d’historique des modifications apportées au Dockerfile ou environment.yml.

Solution : Traitez les spécifications Dockerfile et environnement comme Code. Stockez-les dans Git à côté de votre code de simulation. Libérations de balises (par exemple, git tag -a v1.0 -m "Paper submission").

7. Supervision des services externes

Problème : votre simulation extrait les données d’une base de données ou d’une API qui change avec le temps, ce qui rompt la reproductibilité.

Solution : soit : soit :

  • Snapshot Données externes et incluez-les dans votre référentiel ou votre conteneur, ou
  • Utiliser les points de terminaison d’API versionnés et documenter la version/la date exacte d’accès

Considérations relatives aux HPC et aux clusters

Les environnements de calcul haute performance présentent des défis de reproductibilité supplémentaires :

Singularity/AppTainer au lieu de Docker

La plupart des centres HPC interdisent Docker pour des raisons de sécurité. Au lieu de cela, ils fournissent singularité (ou sa fourchette apptainer). Les conteneurs Singularity sont construits à partir des images Docker :

# On your local machine with Docker
docker pull ubuntu:22.04
docker tag ubuntu:22.04 my-sim:base

# Build your image as usual
docker build -t my-sim:latest .

# Transfer image to HPC and convert
singularity build my-sim.sif docker://my-sim:latest

Différence clé : Singularity exécute des conteneurs en tant qu’utilisateur invoquant (pas de racine), les chemins d’installation du package diffèrent donc. Testez votre Dockerfile avec Singularity pour détecter les problèmes plus tôt.

Systèmes de modules

De nombreux clusters HPC utilisent des modules d’environnement (LMOD) pour gérer les versions logicielles. Vous pouvez soit :

  • Chargez les modules requis avant d’exécuter votre conteneur (si la singularité peut y accéder), ou
  • Créez votre conteneur sur une image de base qui inclut déjà les bibliothèques nécessaires

E/S parallèles et MPI

Si votre simulation utilise MPI (Interface de passage de messages), assurez-vous que votre conteneur inclut une implémentation MPI compatible. Pour Singularity, vous pouvez bind-mount les bibliothèques MPI de l’hôte :

singularity run --nv -B /usr/lib/x86_64-linux-gnu/openmpi:/usr/lib/x86_64-linux-gnu/openmpi my-sim.sif

Vous pouvez également installer MPICH ou OpenMPI à l’intérieur du conteneur et assurez-vous qu’il est configuré pour utiliser la structure de réseau de l’hôte (InfiniBand, etc.).

Prise en charge du GPU

Pour les simulations accélérées par GPU, Docker et Singularity nécessitent des drapeaux spéciaux :

  • Docker : --gpus all
  • Singularité : --nv

Testez soigneusement la fonctionnalité du GPU dans votre conteneur.

Guide de mise en œuvre étape par étape

Voici un flux de travail pratique pour la mise en œuvre de flux de travail de recherche reproductibles dans votre projet de simulation :

Phase 1 : Configuration du projet

  1. Initialiser le contrôle de version (GIT) : 
    git init
git add .
git commit -m "Initial project structure"
  2. Créer un environnement conda : 
    conda create --name my-sim python=3.11
conda activate my-sim
  3. Installer les dépendances et les enregistrer : 
    conda install numpy scipy matplotlib fipy  # Example for PDE simulations
conda env export --no-builds | grep -v "prefix:" > environment.yml
  4. Créer une structure de projet : 
    my-simulation/
├── src/              # Source code
├── scripts/          # Run scripts, entry points
├── data/             # Input data (git-ignored if large)
├── outputs/          # Generated results (git-ignored)
├── docs/             # Documentation
├── environment.yml   # Conda environment
├── requirements.txt  # Pip-only dependencies (if any)
├── Dockerfile        # Container definition
├── README.md         # Usage instructions
└── .gitignore        # Exclude outputs, large data

Phase 2 : Développement avec Conda

  • Développer et tester à l’intérieur de l’environnement Conda
  • Valider les changements de code fréquemment
  • Mettre à jour environment.yml lors de l’ajout/de la suppression de packages
  • Utilisez .gitignore pour exclure les sorties générées et les fichiers volumineux

Phase 3 : construction de l’image Docker

  1. Créer un Dockerfile (voir l’exemple ci-dessus)
  2. Construire l’image : 
    docker build -t my-sim:latest .
  3. Testez le conteneur : 
    docker run -v $(pwd)/data:/data my-sim:latest python scripts/run_simulation.py --input /data/input.h5
  4. Tag pour publication : 
    docker tag my-sim:latest my-sim:paper-v1.0
  5. Pousser vers le registre (facultatif, pour le partage) : 
    docker push my-registry.example.com/my-sim:paper-v1.0

Phase 4 : Vérification et partage

  1. Testez la reproductibilité : demandez à un collègue de tirer et d’exécuter l’image. Ils devraient obtenir des résultats identiques (bit pour bit identiques si la simulation est déterministe).
  2. Document : assurez-vous que README.md comprend :
    • Comment obtenir l’image (docker hub, registre ou .sif fichier)
    • Comment l’exécuter (commande complète)
    • Spécifications des fichiers de saisie
    • Fichiers de sortie attendus et leurs formats
    • Informations sur les citations
  3. Archive : Déposez l’image Docker (ou Singularity .sif) dans une archive à long terme comme Zenodo ou FigShare, et incluez le lien dans les méthodes de votre article ou la déclaration de disponibilité des données.

Phase 5 : Maintenance à long terme

  • Lorsque vous effectuez des modifications de code, mettez à jour l’image et la balise Docker avec une nouvelle version (par exemple, v1.1)
  • Conservez les anciennes images/tags aussi longtemps que vous devez reproduire les anciens résultats
  • Utilisez des balises git pour corréler les validations de code avec les versions d’image Docker

Conclusion et prochaines étapes

La mise en œuvre de workflows de recherche reproductible n’est pas une décision d’un seul outil, c’est une stratégie en couches :

  • CONDA pour une gestion de l’environnement léger et rapide pendant le développement
  • Docker pour des instantanés immuables et portables adaptés à la publication et à la collaboration
  • Git pour le contrôle de version des spécifications de code, de fichiers DockerFile et d’environnement
  • Documentation pour rendre le flux de travail compréhensible et utilisable par d’autres

Pour les projets de simulation où l’exactitude et la vérification sont primordiales, cette combinaison fournit une base robuste. Commencez par Conda pour votre prochain projet, et une fois que la simulation fonctionne, investissez du temps pour créer une image Docker. Le coût initial rapporte des dividendes lorsque vous (ou d’autres) devez réexécuter la simulation des mois ou des années plus tard en toute confiance.

Prochaines étapes à suivre dès aujourd’hui :

  1. Vérifier vos projets de simulation actuels : les environnements sont-ils documentés ? Les dépendances sont-elles épinglées ?
  2. Convertir un projet existant pour utiliser des environnements Conda avec environment.yml
  3. Créez une image Docker pour une simulation de travail et testez-la sur une autre machine
  4. Explorez les stratégies de singularité de votre centre HPC et convertissez une image Docker au format Singularity
  5. Incluez les spécifications d’environnement et les images de conteneurs dans les documents supplémentaires de votre prochain article.

Guides connexes

Références et lectures complémentaires