Reading Time: 21 minutes

Versionnement et provenance des données Python : DVC, DVC et flux de travail scientifiques

Le versioning des données dans la simulation scientifique ne consiste pas à suivre les changements de code – Git gère déjà cela parfaitement. Il s’agit de suivre la combinaison spécifique de fichier de données, de validation de code et de fichier de paramètres produit un résultat particulier. Cette distinction est ce qui sépare un workflow expérimental fragile d’un pipeline de simulation reproductible.

L’outil le plus largement adopté pour cela est DVC (Data Version Control), qui étend le modèle de versionnement de Git pour gérer les grands ensembles de données et les étapes de pipeline. Cet article couvre la mise en œuvre pratique de DVC pour les workflows scientifiques — construction de pipelines avec dvc.yaml, isolation des paramètres avec params.yaml, intégration HPC/Slurm et suivi de provenance W3C émergent. Chiffre d’affaires, migration matérielle et cycles de vie de plusieurs années.

Points à retenir clés

  • Valeur de base de DVC : les fichiers de pipeline (dvc.yaml) rendent les simulations sensibles aux dépendances, donc dvc repro ne réexécute que ce qui a changé.
  • Reproductibilité versionnelle : les instantanés de données DVC relient les fichiers (.dvc), les validations de code (GIT) et les fichiers de paramètres (params.yaml) dans des unités d’expérience reproductibles.
  • Intégration HPC : enveloppes de planification par lots Slurm DVC pour l’exécution du pipeline natif de cluster sans intervention manuelle
  • Normes de provenance : W3C Prov-JSON (YProv4ml) apparaît comme un format interopérable complémentaire aux emballages RO-Crate
  • DVC vs DataLad : choisissez DVC pour les expériences orientées pipeline ; Choisissez DataLad pour la conservation des données à long terme et les jeux de données distribués

Pourquoi la version standard échoue pour les flux de travail de simulation

Git est excellent pour le suivi des changements de code. C’est terrible pour suivre les changements de données.

Lorsque vous exécutez un calcul de relaxation DFT, Git ne peut pas stocker le fichier de structure cristalline .xyz résultant (souvent des dizaines de Mo). Vous pouvez le copier sur un lecteur partagé, ou ajouter son hachage SHA-256 dans un fichier texte ou compter sur la mémoire. Les trois approches se cassent lorsque la source de données change, lorsque vous devez partager avec des collaborateurs qui n’ont pas accès au lecteur partagé ou lorsque vous revenez six mois plus tard et oubliez quel jeu de paramètres a produit la structure d’énergie la plus basse.

Les outils de gestion des données résolvent ce problème en découplant Suivi des données de Suivi de code. Ils stockent des fichiers réels dans le stockage à distance (Google Drive, S3, un NAS partagé ou même un autre référentiel Git) et enregistrent des fichiers pointeurs légers dans le référentiel Git. Les fichiers de pointeur – généralement de petits fichiers .dvc ou les références de liens symboliques Git-annex – contiennent des métadonnées (somme de contrôle, emplacement distant, balise de version) sans dupliquer les données réelles.

Cette séparation est importante pour les flux de travail de simulation, car le volume de données évolue indépendamment du volume du code. Une seule campagne de simulation peut produire des milliers de fichiers de trajectoires, tandis que les scripts Python qui les génèrent restent à quelques centaines de lignes.

L’écart de pipeline

La plupart des chercheurs commencent par le suivi ad hoc des données : un script bash qui exécute les calculs en séquence, avec des résultats copiés dans un répertoire results/ et les nombres finaux collés dans une feuille Google. Cela fonctionne pour de petits projets. Il se décompose lorsque :

  1. Réexécuter avec différents paramètres — Vous devez vous rappeler quel fichier params.yaml a été utilisé et réexécuter uniquement les étapes modifiées
  2. Échecs de débogage : vous devez savoir si l’erreur est née de la corruption des données, des modifications de code ou des incompatibilités de paramètres.
  3. Team Handoff — Un nouvel étudiant ne peut pas reconstruire le pipeline à partir d’un script bash et d’un dossier de fichiers orphelins.

Le fichier de définition de pipeline de DVC (dvc.yaml) corrige cet écart en déclarant des étapes avec des dépendances et des sorties explicites. Chaque étape est réexécutée uniquement lorsque ses dépendances changent (dvc repro <stage>), rendant les campagnes de simulation considérablement plus efficaces lors de la réexécution des calculs avec différents paramètres.

Construction de pipeline DVC pour les flux de travail scientifiques

Un fichier de pipeline DVC est un document YAML déclaratif qui mappe la façon dont vos étapes de simulation dépendent les unes des autres. Voici un exemple concret pour un flux de travail scientifique sur les matériaux informatiques :

# dvc.yaml — DFT relaxation and energy calculation pipeline

stages:
  relax:
    cmd: python src/relax.py
    deps:
    - data/raw_crystal_structure.xyz
    - src/relax.py
    params:
    - params.yaml
    outs:
    - results/relaxed_structure.xyz

  energy:
    cmd: python src/energy.py
    deps:
    - results/relaxed_structure.xyz
    - src/energy.py
    params:
    - params.yaml
    outs:
    - results/energies.txt
    metrics:
    - results/energies.txt

  visualize:
    cmd: python src/plot.py
    deps:
    - results/energies.txt
    - src/plot.py
    outs:
    - figures/energy_plot.png

Chaque étape déclare :

  • cmd : la commande qui génère les sorties de cette étape
  • deps : fichiers qui, s’ils sont modifiés, déclenchent une réexécution de cette étape
  • params : fichiers de paramètres qui, s’ils sont modifiés, déclenchent une réexécution de cette étape
  • outs : fichiers produits par cette étape (suivi comme versions de données)
  • metrics : les fichiers que DVC suit numériquement pour la comparaison d’expériences

Pourquoi params.yaml compte

Le fichier params.yaml isole les paramètres de simulation des scripts d’exécution. Ceci est essentiel pour les workflows de la science des matériaux où le même code de simulation s’exécute des centaines de fois avec des paramètres différents :

# params.yaml
simulator:
  cutoff_energy: 500  # eV
  kpoints: [8, 8, 8]
  tolerance: 1e-6
  
optimization:
  max_steps: 200
  algorithm: ionic

Lorsque vous changez tolerance de 1e-6 à 1e-8 et lancez dvc repro, le DVC détecte le params.yaml et réexécute chaque étape qui en dépend. Le fichier relaxed_structure.xyz résultant obtient une nouvelle balise de version. L’ancienne version reste disponible dans le cache – vous ne perdez pas les exécutions historiques.

Pour les balayages de paramètres, vous pouvez utiliser --set-param pour remplacer les valeurs sans modifier le fichier :

dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450

Cela crée une nouvelle branche d’expérience, conservant à la fois les exécutions originales et modifiées dans l’historique de votre pipeline.

Reproductibilité versionnée — Contribution conceptuelle de DVC

Le blog de DVC (décembre 2021) a introduit la « reproductibilité versionnelle » comme la possibilité de recréer non seulement un résultat, mais aussi l’état expérimental exact qui l’a produit. Cela distingue le DVC du versioning générique :

  • Versioning standard Suivi des modifications apportées aux fichiers au fil du temps (objectif de Git)
  • Reproductibilité en versions Suivi de la version de données spécifiques, de la validation du code et de la combinaison de fichiers de paramètres produit un résultat donné (objectif de DVC)

DVC y parvient en reliant trois artefacts à version indépendante :

Artefact Système de gestion des versions Ce qu’il suit
.dvc Fichiers pointeurs PDV Version du fichier de données + emplacement distant + somme de contrôle
git commet crétin Version du code + message de validation + diff
params.yaml crétin Version du fichier de paramètres + modifications au niveau du champ

La combinaison de ces trois crée une unité reproductible – une « expérience versionnelle » qui peut être reconstruite isolément. Cela compte pour la simulation, car les expériences sont affinées de manière itérative. Les chercheurs ont besoin de savoir « ce qui a fonctionné » et de pouvoir le reproduire sans relancer chaque étape intermédiaire.

Implications pratiques

Lorsqu’un examinateur demande les données derrière un chiffre publié, vous pouvez fournir :

  1. Le hachage de commit git (version de code)
  2. La référence de fichier de pointeur .dvc (version de données)
  3. le fichier params.yaml à ce commit (version du paramètre)

Combinés, ces trois artefacts sont suffisants pour reproduire le résultat sur n’importe quelle machine. Il s’agit de la référence en matière de reproductibilité de simulation – bien au-delà des conteneurs (qui fige les environnements de code) ou des référentiels Git nus (qui ne peuvent pas gérer les données volumineuses).

Expérimentez la file d’attente et la gestion

La gestion des expériences de DVC (dvc exp) étend le modèle de pipeline pour prendre en charge les expériences simultanées et en file d’attente :

# Run a single experiment with custom parameters
dvc exp run -S sim.tolerance=1e-8

# Queue multiple experiments
dvc exp run --queue -S sim.tolerance=1e-8
dvc exp run --queue -S sim.tolerance=1e-6
dvc exp run --queue -S sim.tolerance=1e-5

# Execute queued experiments
dvc exp run

L’indicateur --queue reporte l’exécution, vous permettant de préparer plusieurs expériences et de les exécuter par lots de manière séquentielle. Ceci est utile pour les expériences de calcul qui durent des heures ou des jours. Vous pouvez mettre en file d’attente un balayage des paramètres du jour au lendemain sans lancer manuellement chaque exécution.

Pour la comparaison d’expériences, DVClive fournit le suivi des mesures en temps réel :

# src/metrics.py — DVCLive integration
from dvclive import Live

with Live() as live:
    for step in range(n_iterations):
        result = run_step(step)
        live.step = step
        live.log("energy", result["total_energy"])
        live.log("forces", result["max_force"])

Cela produit un tableau de bord de comparaison interactif où vous pouvez voir comment l’énergie et les forces évoluent à travers les balayages de paramètres.

Exécution de pipelines DVC sur des clusters HPC

La plupart des scientifiques informatiques n’exécutent pas de pipelines sur des ordinateurs portables. Ils les exécutent sur des clusters avec Slurm, PBS ou LSF. DVC s’intègre avec Slurm via le wrapper srun, permettant l’exécution du pipeline natif de cluster :

# Run a single pipeline stage with SLURM resource allocation
srun dvc repro -n relax --job slurm-job.sh

# Run all pipeline stages on the cluster
srun dvc repro

L’indicateur --job indique à DVC d’exécuter chaque étape à travers le planificateur de travaux de Slurm, en s’occupant automatiquement :

  • Allocation de ressources spécifiques au cluster (mémoire, CPU, nœuds GPU)
  • Exécution en mode batch sans intervention manuelle
  • Mise en file d’attente automatique des travaux pour les étapes du pipeline
  • Intégration avec les systèmes de fichiers et le stockage spécifiques aux clusters (Lustre, GPFS, BEEGFS)

ARXIV 2505.06558v2 (septembre 2025) illustre cette intégration pour les flux de travail des matériaux-sciences exécutant des calculs DFT sur les clusters HPC. L’avantage principal est que dvc repro devient conscient des clusters – si une étape échoue ou que ses dépendances changent, SLURM gère l’allocation de ressources pour la réexécution uniquement des étapes nécessaires.

Considérations relatives au stockage des clusters

Le stockage à distance de DVC fonctionne bien avec les systèmes de fichiers de cluster. Vous pouvez configurer DVC pour utiliser le système de fichiers Lustre ou GPFS du cluster en tant que télécommande DVC :

# Configure a cluster storage remote
dvc remote modify cluster_storage token_url "https://cluster-storage.example.com"

Cela évite la surcharge de copie des données vers/depuis le stockage externe en nuage et maintient le pipeline autonome dans la hiérarchie de stockage du cluster.

Suivi de provenance W3C Prov-JSON

Alors que DVC suit les étapes du pipeline et les versions de données, il ne produit pas de graphe de provenance actionnable par la machine. Pour cela, vous avez besoin d’une norme de provenance – et le format émergent est le W3C Prov-JSON.

YProv4ml (ARXIV juillet 2025) implémente la provenance W3C Prov-JSON avec des modifications de code minimales. Il capture :

  • Qui a exécuté l’expérience (identité de l’utilisateur)
  • Quoi Données et codes ont été utilisés (Source Provenance)
  • Comment L’expérience s’est déroulée (provenance d’exécution)
  • Pourquoi (motivation facultative, liée aux objectifs de recherche)

La sortie est un graphe prov-json – un graphe dirigé où les nœuds représentent les entités (fichiers, paramètres, commits de code) et les bords représentent les relations (dérivées, produites par, utilisées). Ce format permet :

  • Interopérabilité entre les systèmes de provenance : Prov-JSON est lisible par machine et peut être interrogée avec des bases de données SparQL ou Graph.
  • Conformité des données équitables : les graphiques Prov-JSON satisfont aux principes équitables en documentant la lignée de données et les conditions de réutilisation
  • Collaboration interinstitutionnelle : Prov-JSON est une norme W3C, de sorte que les graphiques de provenance de différentes institutions sont compatibles

Prov-JSON vs RO-Crate

Il est utile de distinguer Prov-JSON de RO-Crate, puisque les deux apparaissent dans les discussions sur la reproductibilité :

aspect ro-caisse Prov-json
But Format de package pour les métadonnées riches Format de données pour les graphiques de provenance
Portée Ensemble de données entières + ressources associées Ligne d’exécution et dépendances
Format JSON-LD JSON (norme PROV)
interopérabilité Forfait autonome Basé sur des graphes, interrogeable
Relations Complémentaire, non concurrent

Ils abordent différentes couches de reproductibilité. RO-Crate regroupe votre jeu de données avec des métadonnées. Prov-JSON suit la lignée de calcul de la façon dont cet ensemble de données a été produit. L’utilisation des deux ensemble fournit une reproductibilité complète : « voici les données » (ro-crate) plus « voici comment elles ont été produites » (prov-json).

Quand utiliser les bibliothèques DVC vs DataLad vs Prov

Le choix entre les bibliothèques DVC, DataLad et Prov-Conformes dépend de vos modèles de flux de travail :

Critère PDV datalad Bibliaires Prov
Cas d’utilisation principal Expériences orientées pipeline Curation à long terme des données Provenance à la machine
Taille des données Fichiers volumineux (modèles, simulations) Grands ensembles de données distribuées N/A (focalisé sur les métadonnées)
Modèle d’exécution Pipeline sur scène (dvc repro) Basé sur la commande (datalad run) à base de décorateur
Intégration HPC srun dvc repro Native Git-Annex + SSH configurable
Provenance de sortie .dvc Fichiers + Historique des Git Liens symboliques git-annex + journal git Graphique Prov-JSON
le mieux pour Pipelines de matériaux-sciences, balayages de paramètres Curation de référentiel à long terme, conformité des offres Données équitables, provenance interinstitutionnelle

DVC est fait pour vous si :

  • Votre workflow comporte plusieurs étapes dépendantes (relaxation → Calcul des propriétés → visualisation)
  • Vous avez besoin de balayages de paramètres avec une réexécution automatique
  • Vous souhaitez suivre la combinaison de paramètres produit le résultat d’énergie la plus faible

Datalad est fait pour vous si :

  • Vous conservez un référentiel de jeux de données à long terme
  • Vous avez besoin de liens symboliques Git-Annex pour une gestion efficace des fichiers volumineux
  • Vous travaillez avec des ensembles de données distribués entre les institutions
  • Vous avez besoin de la conformité des soumissions (commune en neuroimagerie)

Les bibliothèques conformes à Prov vous conviennent si :

  • Vous avez besoin d’une provenance à la machine pour une conformité équitable
  • Vous voulez un graphe de provenance interrogeable pour la lignée de données
  • Vous collaborez entre des institutions avec différents systèmes de provenance
  • Vous publiez dans un référentiel de données équitable

Mettre en place — un flux de travail pratique

Voici un modèle de flux de travail pratique qui combine tous les concepts ci-dessus :

# 1. Initialize the repository
git init
dvc init

# 2. Add the data
dvc add data/raw_crystal_structure.xyz

# 3. Run the pipeline
dvc repro

# 4. Check the results
dvc metrics show results/energies.txt

# 5. Run experiments with different parameters
dvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550

# 6. Push data and experiments to remote
dvc push
dvc exp push
git push origin main

# 7. (Optional) Generate PROV-JSON provenance
python src/provenance.py --output provenance.json

Ce modèle garantit que chaque résultat de simulation peut être retracé vers sa version exacte des données, sa validation de code et son fichier de paramètres. La sortie Prov-JSON (étape 7) ajoute une couche de provenance actionnable par la machine au-dessus du pipeline DVC.

Erreurs courantes – ce qu’il faut éviter

Erreur 1 : version de tout — Ne pas exécuter dvc add sur chaque fichier de sortie. Ne suivez que les fichiers qui sont des entrées dans les étapes suivantes ou qui représentent les résultats finaux. Les fichiers intermédiaires (comme les tableaux de force brutes) doivent rester dans Git ou être entièrement exclus. L’ajout excessif crée du bruit de pipeline.

Erreur 2 : chemins de codage en dur — N’utilisez pas de chemins absolus dans dvc.yaml. Utilisez des chemins relatifs afin que le pipeline fonctionne sur différentes configurations de machines et de clusters.

Erreur 3 : Mélanger les types de données — Ne placez pas les paramètres de simulation et les points de contrôle du modèle dans le même fichier .dvc. Gardez les types de données séparés pour éviter les conflits de cache.

Erreur 4 : ignorer la provenance — Les fichiers DVC seuls ne sont pas suffisants pour une conformité équitable. Si votre établissement a besoin de graphiques de provenance, associez DVC à une sortie Prov-JSON (YProv4ml) ou à un emballage RO-crate.

Erreur 5 : Oublier params.yaml — Si vous codez en dur les paramètres de vos scripts au lieu de les isoler dans params.yaml, le suivi des paramètres de DVC devient inutile. Utilisez toujours params.yaml pour les paramètres de simulation.

Résumé

DVC transforme les flux de travail scientifiques à partir de processus fragiles et dépendant de la mémoire en pipelines déterministes et sensibles aux dépendances. L’idée clé est que dvc.yaml les fichiers de pipeline et params.yaml l’isolation des paramètres créent une « reproductibilité versionnelle » – la possibilité de reconstruire non seulement un résultat, mais aussi l’état expérimental exact (data version + code commit + fichier de paramètre) qui l’a produit. Cela va au-delà des conteneurs (qui gelent les environnements de code) et au-delà de Git (qui ne peuvent pas gérer les grands ensembles de données).

Pour l’intégration de HPC, le wrapper de Slurm srun permet l’exécution du pipeline natif du cluster sans intervention manuelle. Pour la provenance, le W3C PROV-JSON (YProv4ml) apparaît comme un format interopérable complémentaire à l’emballage RO-crate, permettant une lignée de données actionnable qui répond aux exigences de conformité équitables.

Le choix entre les bibliothèques DVC, DataLad et Prov-Conformes dépend de vos modèles de flux de travail : DVC pour les expériences orientées pipeline, DataLad pour la conservation des données à long terme et les bibliothèques Prov pour les graphes de provenance actionnables par la machine. La plupart des équipes de simulation bénéficient de l’utilisation de DVC pour l’exécution du pipeline et de Prov-JSON pour le suivi de la provenance – les deux outils sont complémentaires et non concurrents.

Guides connexes

<tool_call>
<function=fs_write_file>
<parameter=content>

Versionnement et provenance des données Python : DVC, DVC et flux de travail scientifiques

Le versioning des données dans la simulation scientifique ne consiste pas à suivre les changements de code – Git gère déjà cela parfaitement. Il s’agit de suivre la combinaison spécifique de fichier de données, de validation de code et de fichier de paramètres produit un résultat particulier. Cette distinction est ce qui sépare un workflow expérimental fragile d’un pipeline de simulation reproductible.

L’outil le plus largement adopté pour cela est DVC (Data Version Control), qui étend le modèle de versionnement de Git pour gérer les grands ensembles de données et les étapes de pipeline. Cet article couvre la mise en œuvre pratique de DVC pour les workflows scientifiques — construction de pipelines avec dvc.yaml, isolation des paramètres avec params.yaml, intégration HPC/Slurm et suivi de provenance W3C émergent. Chiffre d’affaires, migration matérielle et cycles de vie de plusieurs années.

Points à retenir clés

  • Valeur de base de DVC : les fichiers de pipeline (dvc.yaml) rendent les simulations sensibles aux dépendances, donc dvc repro ne réexécute que ce qui a changé.
  • Reproductibilité versionnelle : les instantanés de données DVC relient les fichiers (.dvc), les validations de code (GIT) et les fichiers de paramètres (params.yaml) dans des unités d’expérience reproductibles.
  • Intégration HPC : enveloppes de planification par lots Slurm DVC pour l’exécution du pipeline natif de cluster sans intervention manuelle
  • Normes de provenance : W3C Prov-JSON (YProv4ml) apparaît comme un format interopérable complémentaire aux emballages RO-Crate
  • DVC vs DataLad : choisissez DVC pour les expériences orientées pipeline ; Choisissez DataLad pour la conservation des données à long terme et les jeux de données distribués

Pourquoi la version standard échoue pour les flux de travail de simulation

Git est excellent pour le suivi des changements de code. C’est terrible pour suivre les changements de données.

Lorsque vous exécutez un calcul de relaxation DFT, Git ne peut pas stocker le fichier de structure cristalline .xyz résultant (souvent des dizaines de Mo). Vous pouvez le copier sur un lecteur partagé, ou ajouter son hachage SHA-256 dans un fichier texte ou compter sur la mémoire. Les trois approches se cassent lorsque la source de données change, lorsque vous devez partager avec des collaborateurs qui n’ont pas accès au lecteur partagé ou lorsque vous revenez six mois plus tard et oubliez quel jeu de paramètres a produit la structure d’énergie la plus basse.

Les outils de gestion des données résolvent ce problème en découplant Suivi des données de Suivi de code. Ils stockent des fichiers réels dans le stockage à distance (Google Drive, S3, un NAS partagé ou même un autre référentiel Git) et enregistrent des fichiers pointeurs légers dans le référentiel Git. Les fichiers de pointeur – généralement de petits fichiers .dvc ou les références de liens symboliques Git-annex – contiennent des métadonnées (somme de contrôle, emplacement distant, balise de version) sans dupliquer les données réelles.

Cette séparation est importante pour les flux de travail de simulation, car le volume de données évolue indépendamment du volume du code. Une seule campagne de simulation peut produire des milliers de fichiers de trajectoires, tandis que les scripts Python qui les génèrent restent à quelques centaines de lignes.

L’écart de pipeline

La plupart des chercheurs commencent par le suivi ad hoc des données : un script bash qui exécute les calculs en séquence, avec des résultats copiés dans un répertoire results/ et les nombres finaux collés dans une feuille Google. Cela fonctionne pour de petits projets. Il se décompose lorsque :

  1. Réexécuter avec différents paramètres — Vous devez vous rappeler quel fichier params.yaml a été utilisé et réexécuter uniquement les étapes modifiées
  2. Échecs de débogage : vous devez savoir si l’erreur est née de la corruption des données, des modifications de code ou des incompatibilités de paramètres.
  3. Team Handoff — Un nouvel étudiant ne peut pas reconstruire le pipeline à partir d’un script bash et d’un dossier de fichiers orphelins.

Le fichier de définition de pipeline de DVC (dvc.yaml) corrige cet écart en déclarant des étapes avec des dépendances et des sorties explicites. Chaque étape est réexécutée uniquement lorsque ses dépendances changent (dvc repro <stage>), rendant les campagnes de simulation considérablement plus efficaces lors de la réexécution des calculs avec différents paramètres.

Construction de pipeline DVC pour les flux de travail scientifiques

Un fichier de pipeline DVC est un document YAML déclaratif qui mappe la façon dont vos étapes de simulation dépendent les unes des autres. Voici un exemple concret pour un flux de travail scientifique sur les matériaux informatiques :

# dvc.yaml — DFT relaxation and energy calculation pipeline

stages:
  relax:
    cmd: python src/relax.py
    deps:
    - data/raw_crystal_structure.xyz
    - src/relax.py
    params:
    - params.yaml
    outs:
    - results/relaxed_structure.xyz

  energy:
    cmd: python src/energy.py
    deps:
    - results/relaxed_structure.xyz
    - src/energy.py
    params:
    - params.yaml
    outs:
    - results/energies.txt
    metrics:
    - results/energies.txt

  visualize:
    cmd: python src/plot.py
    deps:
    - results/energies.txt
    - src/plot.py
    outs:
    - figures/energy_plot.png

Chaque étape déclare :

  • cmd : la commande qui génère les sorties de cette étape
  • deps : fichiers qui, s’ils sont modifiés, déclenchent une réexécution de cette étape
  • params : fichiers de paramètres qui, s’ils sont modifiés, déclenchent une réexécution de cette étape
  • outs : fichiers produits par cette étape (suivi comme versions de données)
  • metrics : les fichiers que DVC suit numériquement pour la comparaison d’expériences

Pourquoi params.yaml compte

Le fichier params.yaml isole les paramètres de simulation des scripts d’exécution. Ceci est essentiel pour les workflows de la science des matériaux où le même code de simulation s’exécute des centaines de fois avec des paramètres différents :

# params.yaml
simulator:
  cutoff_energy: 500  # eV
  kpoints: [8, 8, 8]
  tolerance: 1e-6
  
optimization:
  max_steps: 200
  algorithm: ionic

Lorsque vous changez tolerance de 1e-6 à 1e-8 et lancez dvc repro, le DVC détecte le params.yaml et réexécute chaque étape qui en dépend. Le fichier relaxed_structure.xyz résultant obtient une nouvelle balise de version. L’ancienne version reste disponible dans le cache – vous ne perdez pas les exécutions historiques.

Pour les balayages de paramètres, vous pouvez utiliser --set-param pour remplacer les valeurs sans modifier le fichier :

dvc exp run --set-param sim.tolerance=1e-8 --set-param sim.cutoff_energy=450

Cela crée une nouvelle branche d’expérience, conservant à la fois les exécutions originales et modifiées dans l’historique de votre pipeline.

Reproductibilité versionnée — Contribution conceptuelle de DVC

Le blog de DVC (décembre 2021) a introduit la « reproductibilité versionnelle » comme la possibilité de recréer non seulement un résultat, mais aussi l’état expérimental exact qui l’a produit. Cela distingue le DVC du versioning générique :

  • Versioning standard Suivi des modifications apportées aux fichiers au fil du temps (objectif de Git)
  • Reproductibilité en versions Suivi de la version de données spécifiques, de la validation du code et de la combinaison de fichiers de paramètres produit un résultat donné (objectif de DVC)

DVC y parvient en reliant trois artefacts à version indépendante :

Artefact Système de gestion des versions Ce qu’il suit
.dvc Fichiers pointeurs PDV Version du fichier de données + emplacement distant + somme de contrôle
git commet crétin Version du code + message de validation + diff
params.yaml crétin Version du fichier de paramètres + modifications au niveau du champ

La combinaison de ces trois crée une unité reproductible – une « expérience versionnelle » qui peut être reconstruite isolément. Cela compte pour la simulation, car les expériences sont affinées de manière itérative. Les chercheurs ont besoin de savoir « ce qui a fonctionné » et de pouvoir le reproduire sans relancer chaque étape intermédiaire.

Implications pratiques

Lorsqu’un examinateur demande les données derrière un chiffre publié, vous pouvez fournir :

  1. Le hachage de commit git (version de code)
  2. La référence de fichier de pointeur .dvc (version de données)
  3. le fichier params.yaml à ce commit (version du paramètre)

Combinés, ces trois artefacts sont suffisants pour reproduire le résultat sur n’importe quelle machine. Il s’agit de la référence en matière de reproductibilité de simulation – bien au-delà des conteneurs (qui fige les environnements de code) ou des référentiels Git nus (qui ne peuvent pas gérer les données volumineuses).

Expérimentez la file d’attente et la gestion

La gestion des expériences de DVC (dvc exp) étend le modèle de pipeline pour prendre en charge les expériences simultanées et en file d’attente :

# Run a single experiment with custom parameters
dvc exp run -S sim.tolerance=1e-8

# Queue multiple experiments
dvc exp run --queue -S sim.tolerance=1e-8
dvc exp run --queue -S sim.tolerance=1e-6
dvc exp run --queue -S sim.tolerance=1e-5

# Execute queued experiments
dvc exp run

L’indicateur --queue reporte l’exécution, vous permettant de préparer plusieurs expériences et de les exécuter par lots de manière séquentielle. Ceci est utile pour les expériences de calcul qui durent des heures ou des jours. Vous pouvez mettre en file d’attente un balayage des paramètres du jour au lendemain sans lancer manuellement chaque exécution.

Pour la comparaison d’expériences, DVClive fournit le suivi des mesures en temps réel :

# src/metrics.py — DVCLive integration
from dvclive import Live

with Live() as live:
    for step in range(n_iterations):
        result = run_step(step)
        live.step = step
        live.log("energy", result["total_energy"])
        live.log("forces", result["max_force"])

Cela produit un tableau de bord de comparaison interactif où vous pouvez voir comment l’énergie et les forces évoluent à travers les balayages de paramètres.

Exécution de pipelines DVC sur des clusters HPC

La plupart des scientifiques informatiques n’exécutent pas de pipelines sur des ordinateurs portables. Ils les exécutent sur des clusters avec Slurm, PBS ou LSF. DVC s’intègre avec Slurm via le wrapper srun, permettant l’exécution du pipeline natif de cluster :

# Run a single pipeline stage with SLURM resource allocation
srun dvc repro -n relax --job slurm-job.sh

# Run all pipeline stages on the cluster
srun dvc repro

L’indicateur --job indique à DVC d’exécuter chaque étape à travers le planificateur de travaux de Slurm, en s’occupant automatiquement :

  • Allocation de ressources spécifiques au cluster (mémoire, CPU, nœuds GPU)
  • Exécution en mode batch sans intervention manuelle
  • Mise en file d’attente automatique des travaux pour les étapes du pipeline
  • Intégration avec les systèmes de fichiers et le stockage spécifiques aux clusters (Lustre, GPFS, BEEGFS)

ARXIV 2505.06558v2 (septembre 2025) illustre cette intégration pour les flux de travail des matériaux-sciences exécutant des calculs DFT sur les clusters HPC. L’avantage principal est que dvc repro devient conscient des clusters – si une étape échoue ou que ses dépendances changent, SLURM gère l’allocation de ressources pour la réexécution uniquement des étapes nécessaires.

Considérations relatives au stockage des clusters

Le stockage à distance de DVC fonctionne bien avec les systèmes de fichiers de cluster. Vous pouvez configurer DVC pour utiliser le système de fichiers Lustre ou GPFS du cluster en tant que télécommande DVC :

# Configure a cluster storage remote
dvc remote modify cluster_storage token_url "https://cluster-storage.example.com"

Cela évite la surcharge de copie des données vers/depuis le stockage externe en nuage et maintient le pipeline autonome dans la hiérarchie de stockage du cluster.

Suivi de provenance W3C Prov-JSON

Alors que DVC suit les étapes du pipeline et les versions de données, il ne produit pas de graphe de provenance actionnable par la machine. Pour cela, vous avez besoin d’une norme de provenance – et le format émergent est le W3C Prov-JSON.

YProv4ml (ARXIV juillet 2025) implémente la provenance W3C Prov-JSON avec des modifications de code minimales. Il capture :

  • Qui a exécuté l’expérience (identité de l’utilisateur)
  • Quoi Données et codes ont été utilisés (Source Provenance)
  • Comment L’expérience s’est déroulée (provenance d’exécution)
  • Pourquoi (motivation facultative, liée aux objectifs de recherche)

La sortie est un graphe prov-json – un graphe dirigé où les nœuds représentent les entités (fichiers, paramètres, commits de code) et les bords représentent les relations (dérivées, produites par, utilisées). Ce format permet :

  • Interopérabilité entre les systèmes de provenance : Prov-JSON est lisible par machine et peut être interrogée avec des bases de données SparQL ou Graph.
  • Conformité des données équitables : les graphiques Prov-JSON satisfont aux principes équitables en documentant la lignée de données et les conditions de réutilisation
  • Collaboration interinstitutionnelle : Prov-JSON est une norme W3C, de sorte que les graphiques de provenance de différentes institutions sont compatibles

Prov-JSON vs RO-Crate

Il est utile de distinguer Prov-JSON de RO-Crate, puisque les deux apparaissent dans les discussions sur la reproductibilité :

aspect ro-caisse Prov-json
But Format de package pour les métadonnées riches Format de données pour les graphiques de provenance
Portée Ensemble de données entières + ressources associées Ligne d’exécution et dépendances
Format JSON-LD JSON (norme PROV)
interopérabilité Forfait autonome Basé sur des graphes, interrogeable
Relations Complémentaire, non concurrent

Ils abordent différentes couches de reproductibilité. RO-Crate regroupe votre jeu de données avec des métadonnées. Prov-JSON suit la lignée de calcul de la façon dont cet ensemble de données a été produit. L’utilisation des deux ensemble fournit une reproductibilité complète : « voici les données » (ro-crate) plus « voici comment elles ont été produites » (prov-json).

Quand utiliser les bibliothèques DVC vs DataLad vs Prov

Le choix entre les bibliothèques DVC, DataLad et Prov-Conformes dépend de vos modèles de flux de travail :

Critère PDV datalad Bibliaires Prov
Cas d’utilisation principal Expériences orientées pipeline Curation à long terme des données Provenance à la machine
Taille des données Fichiers volumineux (modèles, simulations) Grands ensembles de données distribuées N/A (focalisé sur les métadonnées)
Modèle d’exécution Pipeline sur scène (dvc repro) Basé sur la commande (datalad run) à base de décorateur
Intégration HPC srun dvc repro Native Git-Annex + SSH configurable
Provenance de sortie .dvc Fichiers + Historique des Git Liens symboliques git-annex + journal git Graphique Prov-JSON
le mieux pour Pipelines de matériaux-sciences, balayages de paramètres Curation de référentiel à long terme, conformité des offres Données équitables, provenance interinstitutionnelle

DVC est fait pour vous si :

  • Votre workflow comporte plusieurs étapes dépendantes (relaxation → Calcul des propriétés → visualisation)
  • Vous avez besoin de balayages de paramètres avec une réexécution automatique
  • Vous souhaitez suivre la combinaison de paramètres produit le résultat d’énergie la plus faible

Datalad est fait pour vous si :

  • Vous conservez un référentiel de jeux de données à long terme
  • Vous avez besoin de liens symboliques Git-Annex pour une gestion efficace des fichiers volumineux
  • Vous travaillez avec des ensembles de données distribués entre les institutions
  • Vous avez besoin de la conformité des soumissions (commune en neuroimagerie)

Les bibliothèques conformes à Prov vous conviennent si :

  • Vous avez besoin d’une provenance à la machine pour une conformité équitable
  • Vous voulez un graphe de provenance interrogeable pour la lignée de données
  • Vous collaborez entre des institutions avec différents systèmes de provenance
  • Vous publiez dans un référentiel de données équitable

Mettre en place — un flux de travail pratique

Voici un modèle de flux de travail pratique qui combine tous les concepts ci-dessus :

# 1. Initialize the repository
git init
dvc init

# 2. Add the data
dvc add data/raw_crystal_structure.xyz

# 3. Run the pipeline
dvc repro

# 4. Check the results
dvc metrics show results/energies.txt

# 5. Run experiments with different parameters
dvc exp run -S sim.tolerance=1e-8 --set-param sim.cutoff_energy=550

# 6. Push data and experiments to remote
dvc push
dvc exp push
git push origin main

# 7. (Optional) Generate PROV-JSON provenance
python src/provenance.py --output provenance.json

Ce modèle garantit que chaque résultat de simulation peut être retracé vers sa version exacte des données, sa validation de code et son fichier de paramètres. La sortie Prov-JSON (étape 7) ajoute une couche de provenance actionnable par la machine au-dessus du pipeline DVC.

Erreurs courantes – ce qu’il faut éviter

Erreur 1 : version de tout — Ne pas exécuter dvc add sur chaque fichier de sortie. Ne suivez que les fichiers qui sont des entrées dans les étapes suivantes ou qui représentent les résultats finaux. Les fichiers intermédiaires (comme les tableaux de force brutes) doivent rester dans Git ou être entièrement exclus. L’ajout excessif crée du bruit de pipeline.

Erreur 2 : chemins de codage en dur — N’utilisez pas de chemins absolus dans dvc.yaml. Utilisez des chemins relatifs afin que le pipeline fonctionne sur différentes configurations de machines et de clusters.

Erreur 3 : Mélanger les types de données — Ne placez pas les paramètres de simulation et les points de contrôle du modèle dans le même fichier .dvc. Gardez les types de données séparés pour éviter les conflits de cache.

Erreur 4 : ignorer la provenance — Les fichiers DVC seuls ne sont pas suffisants pour une conformité équitable. Si votre établissement a besoin de graphiques de provenance, associez DVC à une sortie Prov-JSON (YProv4ml) ou à un emballage RO-crate.

Erreur 5 : Oublier params.yaml — Si vous codez en dur les paramètres de vos scripts au lieu de les isoler dans params.yaml, le suivi des paramètres de DVC devient inutile. Utilisez toujours params.yaml pour les paramètres de simulation.

Résumé

DVC transforme les flux de travail scientifiques à partir de processus fragiles et dépendant de la mémoire en pipelines déterministes et sensibles aux dépendances. L’idée clé est que dvc.yaml les fichiers de pipeline et params.yaml l’isolation des paramètres créent une « reproductibilité versionnelle » – la possibilité de reconstruire non seulement un résultat, mais aussi l’état expérimental exact (data version + code commit + fichier de paramètre) qui l’a produit. Cela va au-delà des conteneurs (qui gelent les environnements de code) et au-delà de Git (qui ne peuvent pas gérer les grands ensembles de données).

Pour l’intégration de HPC, le wrapper de Slurm srun permet l’exécution du pipeline natif du cluster sans intervention manuelle. Pour la provenance, le W3C PROV-JSON (YProv4ml) apparaît comme un format interopérable complémentaire à l’emballage RO-crate, permettant une lignée de données actionnable qui répond aux exigences de conformité équitables.

Le choix entre les bibliothèques DVC, DataLad et Prov-Conformes dépend de vos modèles de flux de travail : DVC pour les expériences orientées pipeline, DataLad pour la conservation des données à long terme et les bibliothèques Prov pour les graphes de provenance actionnables par la machine. La plupart des équipes de simulation bénéficient de l’utilisation de DVC pour l’exécution du pipeline et de Prov-JSON pour le suivi de la provenance – les deux outils sont complémentaires et non concurrents.

Guides connexes