Référentiel de dynamique moléculaire : un guide pratique

Un référentiel de dynamique moléculaire est un hôte à version contrôlée pour le code de simulation, les ensembles de données d’entrée, les paramètres de champ de force et les scripts d’analyse, couvrant des moteurs tels que GROMACS, LAMMPS et OpenMM ainsi que des formats de trajectoire tels que DCD et XTC. Les choix de stockage sont importants à grande échelle : un système de 100 000 atomes simulé pendant 100 nanosecondes avec des coordonnées écrites toutes les 10 picosecondes produit environ 10 000 images, donc la bonne structure détermine si une simulation reste reproductible des années plus tard.

Points clés à retenir

• Un référentiel de dynamique moléculaire n’est pas une chose : c’est une pile de code moteur, de définitions de champs de force, de fichiers de topologie et de coordonnées, de scripts d’exécution et de notebooks d’analyse, chacun avec des besoins de version différents.
• Les formats de trajectoire binaires (XTC, DCD, TRR, NetCDF/AMBER) échangent la précision contre la taille ; le choix affecte à la fois le coût de stockage et la lisibilité à long terme.
• La reproductibilité dépend moins du moteur que de l’épinglage de quatre éléments : la version du moteur, la version du champ de force, la graine aléatoire et le fichier d’entrée exact.
• Git est le bon outil pour les saisies de texte et les scripts, mais les grandes trajectoires binaires appartiennent à Git LFS, DVC ou à un référentiel de données tel que Zenodo – et non à l’historique principal de Git.
• Les principes de données FAIR (trouvables, accessibles, interopérables, réutilisables) correspondent clairement aux décisions de disposition du référentiel que vous prenez dès le premier jour.
• Un référentiel qui ne peut pas être réexécuté par un étranger est une documentation et non une reproductibilité.

À quoi fait réellement référence le « référentiel de dynamique moléculaire »

Le référentiel de dynamique moléculaire est une expression surchargée, et son ambiguïté provoque une réelle confusion lorsque les groupes de laboratoire tentent de normaliser. Au moins quatre choses distinctes sont appelées par ce nom, et elles n’ont techniquement presque rien en commun.

Le premier est le référentiel moteur — le code source du programme de simulation lui-même. GROMACS, LAMMPS, NAMD, OpenMM et AMBER vivent chacun dans leurs propres référentiels en amont, et vous interagissez avec eux en tant qu’utilisateur et non en tant que responsable. Ici, vous vous souciez des balises de version et des numéros de version, pas du code.

Le second est le référentiel des champs de force et des paramètres. Les champs de force tels que CHARMM36, AMBER ff14SB, OPLS-AA et la famille Martini à gros grains sont distribués sous forme de fichiers de paramètres, souvent avec leur propre version. Le projet OpenKIM maintient une archive interopérable de potentiels interatomiques pour les matériaux et les systèmes moléculaires, ce qui constitue un modèle de livraison vraiment différent d’un référentiel Git.

Le troisième est le référentiel du projet : votre propre répertoire de travail pour une étude spécifique. Celui-ci contient les fichiers de topologie, les fichiers de coordonnées, .mdp ou les decks d’entrée, les scripts d’exécution et le code d’analyse. C’est de là que proviennent la plupart des échecs de reproductibilité.

Le quatrième est le dépôt de données : une archive à long terme pour les trajectoires, les points de contrôle et les données dérivées. Zenodo, Figshare et les référentiels institutionnels remplissent ce rôle et attribuent des DOI afin qu’un ensemble de données spécifique puisse être cité.

Connexes : Dataquest — Parcours de science des données basés sur des projets avec un terminal guidé et des ensembles de données réels.

Confondre ces quatre conduit à des erreurs prévisibles : committer une trajectoire de 40 Go dans Git, ou traiter un dépôt Zenodo comme s’il s’agissait d’un répertoire de travail actif. Les séparer est la décision la plus déterminante dans la mise en place d’un projet de simulation.

Le problème des données longues : pourquoi les trajectoires interrompent le contrôle normal des versions

Les données longues produites par les simulations de dynamique moléculaire constituent la contrainte déterminante sur la conception du référentiel, et il est important de comprendre pourquoi avant de choisir les outils. Un seul système de 100 000 atomes simulé pendant 100 nanosecondes avec des coordonnées écrites toutes les 10 picosecondes produit de l’ordre de 10 000 images. Stocké sous forme de coordonnées double précision non compressées, soit environ 100 000 atomes × 3 coordonnées × 8 octets × 10 000 images — des centaines de gigaoctets avant toute compression.

Des formats de trajectoire existent justement pour gérer cela. XTC utilise une compression avec perte avec une précision configurable, généralement 3 décimales en nanomètres, et constitue la valeur par défaut pour GROMACS.

Ça vaut le coup d'oeil : Coursera Plus — Un abonnement pour les certificats Python et de science des données soutenus par l'université.

DCD est le format CHARMM classique, non compressé et largement lisible. TRR est le format pleine précision sans perte de GROMACS, utile lorsque vous avez besoin de vitesses ou de forces exactes. Les formats basés sur NetCDF, y compris la convention de trajectoire AMBER, sont auto-descriptifs et contiennent des métadonnées d’unité.

Les conséquences pratiques pour un référentiel sont concrètes :

• Git stocke chaque version de chaque fichier. Une trajectoire qui change à chaque exécution gonflera définitivement un référentiel, car l’historique de Git est en ajout uniquement. Même la suppression du fichier ne récupère pas l’espace sans réécriture de l’historique.
• Git LFS (Large File Storage) remplace les fichiers volumineux par des pointeurs et stocke le contenu ailleurs, ce qui fonctionne bien pour les fichiers jusqu’à quelques gigaoctets qui changent rarement. C’est un mauvais choix pour les trajectoires qui se régénèrent constamment.
• DVC (Data Version Control) suit les données par hachage et les stocke dans une distant configurable — disque local, S3 ou magasin institutionnel — tout en conservant de petits fichiers de pointeur .dvc dans Git. Cela convient aux flux de travail de simulation où les données sont volumineuses et le code petit.
• Les dépôts de données avec DOI sont le lieu idéal pour la version figée et publiée d’une trajectoire. Ce n’est pas un répertoire de travail.

Une division du travail réalisable : Git pour les scripts, les fichiers d’entrée et le code d’analyse ; DVC ou Git LFS pour les artefacts binaires modérés ; une archive émettrice de DOI pour l’ensemble de données final publié. Cela maintient les temps de clonage raisonnables et rend l’enregistrement publié citable.

Anatomie d’un référentiel de simulation reproductible

Un référentiel de dynamique moléculaire reproductible a une présentation prévisible, et la présentation elle-même communique l’intention à quiconque l’ouvre. La structure suivante est une valeur par défaut raisonnable pour un projet de dynamique moléculaire, adaptable aux flux de travail LAMMPS, GROMACS ou OpenMM.

projet/
├── README.md
├── environnement.yml # ou requirements.txt / conda spec
├── systèmes/
│ ├── système-a/
│ │ ├── topologie/
│ │ ├── coordonnées/
│ │ └── paramètres/
│ └── système-b/
├── simulations/
│ ├── équilibrage/
│ │ ├── entrées/
│ │ └── run.sh
│ └── production/
│ ├── entrées/
│ └── run.sh
├── analyse/
│ ├── notebooks/
│ └── scripts/
├── data/ # suivi par DVC ou gitignoré
└──documents/

Chaque répertoire mérite sa place. L’arborescence « systèmes/ » sépare la définition chimique de ce que vous simulez de la façon dont vous le simulez, ce qui est important car le même système est souvent exécuté sous plusieurs protocoles. L’arbre « simulations/ » sépare l’équilibrage de la production, une distinction facile à perdre et coûteuse à reconstruire.

Le fichier environment.yml est le composant le plus sous-estimé. En épinglant la version du moteur, la pile d’analyse Python et toutes les bibliothèques prises en charge dans un seul fichier, un collaborateur peut reconstruire l’environnement avec une seule commande. Les fichiers d’environnement Conda, les fichiers d’exigences « pip » et les définitions de conteneurs (Docker ou Apptainer/Singularity) servent tous à cet effet ; les conteneurs sont les plus robustes car ils capturent également les bibliothèques système.

Connexes : O'Reilly Learning Platform — Une bibliothèque technique approfondie de livres, de vidéos et de formations en informatique scientifique.

Le « README.md » doit indiquer, au minimum : quelle est l’étude, quel moteur et quelle version, quel champ de force et quelle version, comment exécuter le pipeline depuis les entrées brutes jusqu’aux chiffres finaux, et où se trouvent les données volumineuses. Un README qui suppose que le lecteur est l’auteur n’est pas une documentation.

Choisir un hôte de référentiel : des critères importants

L’hébergement de référentiels pour la science informatique s’inscrit dans le cadre de ce que l’hébergement commercial Git ne couvre pas. Le tableau ci-dessous compare les options réellement envisagées par la plupart des groupes de laboratoires lors de la sélection d’un référentiel de dynamique moléculaire.

Hôte/outil	Idéal pour	Gère les gros binaires	DOI / citation	Remarques
GitHub/GitLab	Code, scripts, petites entrées	Via Git LFS (quota limité)	Pas de DOI natif	Omniprésent; Les quotas LFS peuvent vous surprendre
Zénodo	Ensembles de données publiés gelés	Oui, des limites généreuses	Oui, par version DOI	S’intègre aux versions de GitHub
Figshare	Ensembles de données, chiffres, supplémentaires	Oui	Oui	Courant dans les flux de travail des journaux
Dépôt institutionnel	Archivage institutionnel à long terme	Varie	Généralement oui	Persistance liée à l’institution
DVC + télécommande cloud	Versionnement actif de grandes données	Oui	Non	Garde l’historique de Git petit
Open Science Framework	Organisation au niveau du projet	Oui	Oui	Idéal pour les projets mixtes code/données

La décision se résume généralement à trois questions. Les données doivent-elles pouvoir être citées avec un DOI ? Doit-il être versionné au fur et à mesure qu’il change, ou gelé une fois ? Qui est chargé de le maintenir disponible dans dix ans ?

Si vous faites du shopping : DataCamp — Cours interactifs Python et science des données que vous codez directement dans le navigateur.

Un modèle courant et défendable est GitHub pour le code avec l’intégration Zenodo activée, de sorte que chaque version étiquetée crée automatiquement un DOI, plus DVC pour les données de travail. Cela donne des versions citables sans gonfler l’historique de Git.

Champs de force, paramètres et piège de gestion des versions

La gestion des versions par champ de force est le point où la reproductibilité échoue discrètement, et elle mérite un traitement séparé car le mode d’échec est invisible. Deux simulations intitulées « CHARMM36 » exécutées à trois ans d’intervalle peuvent utiliser des ensembles de paramètres différents car les champs de force sont révisés. Il en va de même pour les champs de force de la protéine AMBER, où ff99SB, ff99SB-ILDN, ff14SB et les révisions ultérieures produisent un comportement mesurablement différent.

Le problème est que les fichiers de champs de force sont souvent distribués sur les installations du moteur ou téléchargés à partir d’un site Web de projet, et la version n’est enregistrée nulle part dans la sortie de la simulation. Un référentiel de dynamique moléculaire qui épingle la version moteur mais pas la version champ de force n’est qu’à moitié reproductible.

Atténuations pratiques :

• Intégrez les fichiers de paramètres dans le référentiel. Copiez les fichiers exacts .itp, .prm ou .frcmod utilisés dans systems/*/parameters/ et validez-les. Ce sont de petits fichiers texte, et leur présence dans le référentiel supprime toute ambiguïté.
• Enregistrez le nom et la révision du champ de force dans le README et dans un fichier de métadonnées lisible par machine. Un court fichier YAML ou JSON à côté des entrées ne coûte rien et répond définitivement à la question.
• Notez toutes les modifications locales. Si vous avez ajusté une charge partielle ou un paramètre lié, cette modification doit être dans le référentiel, pas dans un répertoire de travail personnel.
• Pour les potentiels interatomiques dans la simulation des matériaux, préférez une archive versionnée. OpenKIM existe précisément pour rendre les potentiels citables et versionnés, et son utilisation lève une classe d’ambiguïté.

Le principe général : tout ce qui affecte le résultat numérique et n’est pas le binaire du moteur appartient au référentiel en tant que fichier validé.

Reproductibilité au-delà du référentiel : graines, matériel et virgule flottante

Un référentiel de dynamique moléculaire peut être parfaitement organisé mais ne parvient toujours pas à reproduire un résultat, car la dynamique moléculaire a des sources de non-déterminisme qui vivent en dehors du contrôle de version. Les comprendre évite les fausses confiances.

Les graines aléatoires contrôlent l’affectation initiale de la vitesse et, dans les méthodes stochastiques, le comportement du thermostat et du barostat. Si la graine n’est pas enregistrée, l’analyse n’est pas reproductible même avec des entrées identiques. De nombreux moteurs acceptent une graine explicite ; utilisez-le et enregistrez-le.

La décomposition parallèle affecte l’ordre de sommation en virgule flottante. L’exécution du même système sur 16 cœurs contre 64 cœurs peut produire des trajectoires qui divergent dans le temps en raison des différences d’arrondi accumulées. Ce n’est pas un bug ; c’est la nature de l’arithmétique à virgule flottante sous différents ordres de réduction. Pour une reproductibilité stricte, enregistrez la décomposition du domaine et le nombre de cœurs, ou acceptez que l’identité au niveau du bit n’est pas réalisable et visez plutôt une reproductibilité statistique.

Les différences entre le matériel et le compilateur introduisent des variations supplémentaires à travers différentes bibliothèques mathématiques et jeux d’instructions. Les conteneurs réduisent mais n’éliminent pas ce phénomène.

Les choix du thermostat et du barostat changent l’ensemble et donc la physique. Un référentiel doit enregistrer explicitement l’ensemble — NVT, NPT, NVE — ainsi que les constantes de couplage.

Le cadre honnête est que la reproductibilité au niveau du bit est réalisable dans une configuration matérielle et logicielle fixe, et que la reproductibilité statistique est l’objectif réaliste dans toutes les configurations. Un référentiel qui documente la configuration rend le premier réalisable et le second vérifiable.

Principes FAIR appliqués aux données de simulation

Les principes FAIR – Trouvable, Accessible, Interopérable, Réutilisable – ont été formulés pour les données de recherche en général et se traduisent dans des pratiques spécifiques de stockage de dynamique moléculaire.

Trouvable signifie que l’ensemble de données possède un identifiant persistant et des métadonnées descriptives. Un DOI de Zenodo ou d’un référentiel institutionnel satisfait à cela ; ce n’est pas le cas d’un annuaire sur un serveur de laboratoire.

Accessible signifie que les données peuvent être récupérées par un humain ou une machine à l’aide d’un protocole standard, avec une licence claire. Choisir une licence ouverte au moment du dépôt évite la situation courante où les données sont archivées mais légalement inutilisables.

Interopérable signifie que les formats sont standards et documentés. L’utilisation de XTC, DCD ou NetCDF plutôt qu’un format binaire personnalisé et la documentation des unités rendent les trajectoires lisibles par des outils standards des années plus tard.

Réutilisable signifie qu’il existe suffisamment de contexte pour réutiliser les données à d’autres fins. Cela nécessite les métadonnées décrites ci-dessus : version du moteur, version du champ de force, ensemble, température et tout traitement appliqué.

Le cadrage FAIR est utile car il détourne l’attention de « ai-je enregistré les fichiers » vers « quelqu’un d’autre peut-il utiliser ces fichiers ». Ce sont des questions différentes, et seule la seconde compte pour les données longues.

Configuration pratique : un exemple de travail minimal

Une configuration minimale reproductible pour un flux de travail de référentiel de dynamique moléculaire de style GROMACS, adaptable à d’autres moteurs, ressemble à ceci dans la pratique.

Initialisez le référentiel et configurez la gestion des fichiers volumineux :

git init md-project
cd md-project
git lfs install
git lfs track "*.xtc" "*.trr" "*.tpr"
git add .gitattributes

Créez la spécification d’environnement et validez-la avec les entrées :

conda env export --no-builds > environnement.yml
git add environnement.yml systems/ simulations/ analysis/
git commit -m "Configuration initiale reproductible"

Étiquetez les versions afin qu’un DOI puisse être créé et archivez l’ensemble de données gelé séparément du référentiel de travail. La balise marque l’état exact du code ; l’archive contient l’état exact des données.

Le flux de travail ci-dessus est délibérément minimal. L’idée n’est pas la sophistication des outils, mais la discipline consistant à committer les éléments qui déterminent le résultat et à archiver les éléments trop volumineux pour être versionnés.

Sources et lectures complémentaires

• Dynamique moléculaire — Wikipédia : La dynamique moléculaire (MD) est une méthode de simulation informatique permettant d’analyser les mouvements physiques des atomes et des molécules. Les atomes et les molécules peuvent interagir…

Questions fréquemment posées

Qu’est-ce qu’un référentiel de dynamique moléculaire ?

Un référentiel de dynamique moléculaire est un magasin à version contrôlée pour les fichiers qui définissent et reproduisent une simulation : entrées du moteur, fichiers de topologie et de coordonnées, paramètres de champ de force, scripts d’exécution et code d’analyse. Le terme fait également référence aux référentiels sources en amont de moteurs comme GROMACS et LAMMPS, ainsi qu’aux archives de données contenant des trajectoires. Distinguer ces trois utilisations évite la plupart des erreurs de conception de référentiel.

Dois-je stocker les trajectoires MD dans Git ?

Les trajectoires ne doivent généralement pas entrer dans l’historique de Git, car Git stocke chaque version de manière permanente et les gros fichiers binaires gonflent le référentiel de manière irréversible. Git LFS fonctionne pour les fichiers de taille moyenne qui changent rarement, et DVC fonctionne mieux pour les données volumineuses fréquemment régénérées. La version publiée et figée d’une trajectoire appartient à un référentiel de données attribuant des DOI tel que Zenodo.

Comment rendre reproductible une simulation de dynamique moléculaire ?

La reproductibilité nécessite d’épingler la version du moteur, la version du champ de force, la graine aléatoire, les fichiers d’entrée exacts et la configuration du matériel ou du conteneur. La validation des fichiers de paramètres de champ de force dans le référentiel supprime la source la plus courante de divergence silencieuse. La reproductibilité au niveau du bit est réaliste dans une configuration fixe ; sur différents nombres de cœurs ou de matériel, viser la reproductibilité statistique et documenter la différence.

Quel format de trajectoire dois-je utiliser ?

XTC est une bonne valeur par défaut pour les flux de travail GROMACS car il se compresse bien avec une précision configurable. DCD est largement lisible et non compressé, ce qui convient à l’interopérabilité. TRR préserve une précision totale et est utile lorsque les vitesses ou les forces sont importantes. Les formats basés sur NetCDF sont auto-descriptifs et contiennent des métadonnées unitaires, ce qui facilite la réutilisation à long terme.

Ai-je besoin d’un DOI pour mes données de simulation ?

Un DOI est nécessaire si vous souhaitez que l’ensemble de données puisse être cité indépendamment de l’article, ce qui est de plus en plus attendu par les revues et les bailleurs de fonds. Zenodo et Figshare créent tous deux des DOI et s’intègrent aux versions de GitHub, de sorte que le marquage d’une version peut produire automatiquement un identifiant citable. Pour les travaux internes non publiés, un DOI est facultatif, mais la même discipline d’archivage reste payante.

Comment les versions de champ de force doivent-elles être enregistrées ?

Les fichiers de paramètres de champ de force doivent être stockés dans le référentiel sous un répertoire de paramètres et validés, car ce sont de petits fichiers texte et leur contenu exact détermine le résultat. Le nom et la révision du champ de force doivent également être enregistrés dans le README et dans un fichier de métadonnées lisible par machine. Toute modification locale des paramètres ou des paramètres associés doit être validée plutôt que conservée dans un répertoire personnel.