Nous allons explorer l’organisation projet Molegro tel que nous le pratiquons, ce qui se traduit par une arborescence type (répertoires et conventions de noms). Prendre le temps de l’expliquer n’est pas un luxe, car il est compliqué de rentrer dans un système que d’autres ont déjà plus ou moins standardisé. Ce qui est souvent nécessaire dans une démarche de modélisation moléculaire ou il est facile de se perdre dans des fichiers de toute nature : paramétrages, logs de calculs, résultats, structures de composés organiques (ligands ou cofacteurs), structures des macromolécules, structures à différents états (2D, 3D, après calculs, alignées …) et sous différents formats (MDL-Mol, SDF, SMILES, PDB, formats natifs d’applications), rapports, diagrammes …

Publication initiale sur buildblog.buidez.net (2021) – Article mis à jour en Mars 2025.

1. Organisation à la racine du projet

En général nous essayons d’adopter une arborescence des dossiers et un espace de noms (fichiers, dossiers) qui devraient avoir une signification assez simple à comprendre. A cela, il faut ajouter que certaines parties de cette arborescence peuvent être générées par des scripts ou servir d’entrées à des programmes de traitement (en particulier, conversion et agrégation de données). Nous comprendrons donc qu’un certain niveau d’organisation et de normalisation soit souhaitable.
Une arborescence ‘typique’ se précise au fur et à mesure du temps et de la culture de chaque laboratoire. Dans notre cas, pour un projet de docking moléculaire nous trouverons un contenu qui va ressembler à un mélange de répertoires utilitaires et de répertoires liés aux calculs, par exemple :

Cet arbre pourra être plus complexe, suivant les méthodologies utilisées, en particulier s’il y a du développement logiciel qui se greffe sur le projet, plusieurs protéines étudiées (ensemble docking), plusieurs approches de calcul (multimodal et consensus docking). Dans notre exemple il s’agit d’un arbre pour une seule structure (1P45a) mais avec déjà trois protocoles de calcul (GPU, MSE, OPT) et deux fonctions de score pour la recherche: GPU et MolDock.

2. Des répertoires ‘outils’

Partons à la découverte des répertoires de cette arborescence :

Dossier	Pourquoi ?
_frames	Ce répertoire contient plusieurs versions d’une même protéine mais avec des structures différentes, qui rendent compte de la dynamique structurale. Ces frames peuvent être représentatifs d’états conformationnels remarquables de la protéine et être issus de calculs (ex : dynamique moléculaire) ou de fouille de données (avec parfois génération de structures intermédiaires).
_images	Images utiles pour les présentations.
_ligands, _new_ligands	Structures chimiques (composés organiques) des ligands à docker (nouveaux ou ligands de référence) sous plusieurs types de formats de fichiers, sous forme individuelle ou en collection (plusieurs molécules dans le même fichier).
_poses	Meilleures poses issues de protocoles de docking dans le projet, après leur extraction des résultats de calcul, et dans le même espace de coordonnées cartésiennes (espace de référence) de manière à ce qu’on puisse les analyser par superposition (entre elles et avec d’autres ligands). En général des molécules individuelles au format MDL Mol avec des noms adaptés (no de pose, recherche, score) pour les identifier rapidement et les insérer dans d’autres logiciels.
_publication	Ce dossier inclue tout ce qui concerne la rédaction, les figures, calculs secondaires, graphes, le matériel supplémentaire associé à la publication (supplementary material/information). Avec parfois un numéro de versions si nous avons rédigé plusieurs articles à partir du projet.
_these	Parfois ce dossier est présent et regroupe le matériel (tout type) à intégrer dans une thèse.
_reports	Un dossier spécifique aux modélisateurs. Il contient tous les documents relatifs (auto-générés ou écrits d’une manière manuelle) à l’analyse des calculs. En particulier les fichiers reports (format DOCX ou équivalent) qui sont normalisés et associés à des numéros de versions. Ces fichiers correspondent à notre cahier de laboratoire électronique, pour cette arborescence.
_views	Fichiers Python .py ou .pyc qui sont des représentations de la structure générées avec UCSF Chimera et utilisées pour la conception ou la génération d’images à intégrer dans les livrables (thèses, reports, publications, présentations).
_publis	Ce répertoire (non affiché) va regrouper les liens (DOI, PubMed …) et fichiers PDF correspondant aux publication d’intérêt dans le projet, notamment concernant les structures cristallographiques et les inhibiteurs. Il se peut aussi que ces données soient regroupées ailleurs (dossier partagé, GED, système bibliographique), tout dépends de l’organisation du laboratoire ou de l’équipe. Il se peut aussi que _publis et _publications s’inversent, il ne s’agit pas de répertoires critiques pour les processus d’analyse et de calcul.

3. Des répertoires ‘calcul’

La partie calcul se retrouve dans les trois répertoires suivants au noms longs qui commencent par la chaine 1P45a (par exemple 1P45a_MSE_MolDock_Flex) et qui contiennent les résultats bruts du docking.
D’après leur noms, on constate que la structure utilisée est 1P45 (chaine A) et que l’algorithme de recherche est basé sur un code GPU (GPGPU) ou sur une méthode évolutionnaire de type MSE ou OPT. La fonction de score principale dans les résultats est MolDock. Les résultats peuvent avoir été obtenus avec une fonction de score différente mais MolDock est utilisée pour la classification finale. Le terme Flex réfère à la prise en compte explicite de la flexibilité de la cavité d’intérêt (site actif, liaison, allostérique, cavité … receptor dans la terminologie Molegro) Le ligand étant toujours flexible selon ses angles de torsion et la direction de certains hydrogènes (ex : groupes OH). Parfois la chaine Flex est associée à un numéro (ex : Flex19 avec le fichier .mvdml) il s’agit du nombre de résidus paramétrés pour prendre en compte la flexibilité de leur chaine latérale (softened potentials).
Nous pourrions trouver d’autres termes tels que Tmpl pour signifier que des templates (terminologie Molegro) sont utilisés. Il s’agit de pharmacophores destinés à ajouter du poids à certaines positions dans l’espace où l’on sait (après une analyse structurale, et donc on en tient compte) que des atomes particuliers sont présents et conservés (par exemple des donneurs ou accepteurs de liaisons hydrogènes). D’autres termes peuvent être présents en fonction de la modélisation, se référant à des charges, contraintes (ex: de distances), molécules d’eau, cofacteur, ligands supplémentaires (ions, autres molécules organiques) présents dans la cavité …
Dans le cas présent, des templates sont bien présents mais ils ne seront mentionnés que dans les noms de sous-répertoire à ces trois dossiers. Il y a toujours un équilibre à respecter entre la complexité d’un nom et sa longueur.

4. Un espace de travail de référence

Enfin on trouve les espaces de travails (workspaces dans la terminologie Molegro) utilisés dans les calculs au format MVDML. Pour le moment dans ce projet il n’y a qu’un workspace, le fichier  frame_06_1P45a_NAD_Flex19_tmpl.mvdml. Le workspace inclue l’ensemble des données pour la modélisation et est généré à partir de l’interface graphique de Molegro. Lorsque nous ouvrons un workspace (MVD ou MMV) nous avons une fenêtre de visualisation à droite, et une hiérarchie d’éléments (panneau workspace explorer) sur lesquels on peut agir (check/uncheck et menus), à gauche.

L’explorateur montre différents éléments, de haut en bas dans la hiérarchie :

• La ou les cavités détectées par Molegro et leurs volumes. Ici une seule cavité, qui peut être utilisée pour contraindre les calculs (affichage désactivé sur la représentation).
• Les cofacteurs, ici le NAD+/NADH, qui se positionne sous le JPL (molécule en vert) et groupe nicotinamide vers la droite, on reconnait rapidement le di-phosphate central.
• Les contraintes: la plupart du temps, il s’agit de la sphère (de l’ordre de 12 à 17 Å de rayon) utilisée par l’algorithme de recherche (search space) pour l’arrimage moléculaire (affichage désactivé sur la représentation). Mais d’autres éléments peuvent entrer dans cette liste, par exemple des contraintes de distances issues de données RMN.
• Les templates, ici il y a deux pharmacophores, on les voit sous la forme de sphères vertes. Chacun correspond à une position moyenne privilégiée pour des atomes accepteurs de liaisons hydrogènes. Il s’agit de groupements (OH, C=O …) qui engagent des interactions avec la tyrosine 158. La TYR158 est représentée parmi d’autres résidus du site actif, on voit qu’il y a une interaction (pointillés bleus) avec le ligand (en vert), d’autres interactions engagent le cofacteur et le ligand.
• Les résidus flexibles, la position de leurs carbones alpha est marquée par une sphère (volumes en représentations ‘fil de fer’ grises).
• Les labels correspondent à des groupes d’annotations (par exemple le nom des résidus).
• Les ligands, soit 39 molécules dans ce workspace. Seule la première molécule (active) JPL_400_3FNG_ est représentée en vert, il s’agit d’un dérivé de triclosan, co-cristallographié dans la structure 3FNG (chaine A, résidu 400). Comme 3FNG_ et 1P45a sont alignées dans l’espace et correspondent à des protéines similaires, il en résulte que les ligands sont également alignés. Le JPL apparaît donc dans le site actif de 1P45a et montre le même type d’interactions que dans 3FNG_. Le début de la liste correspond à des ligands de références, faisant partie d’autres structures alignées de l’enzyme InhA. La fin de la liste (non montrée) correspond aux ligands candidats (nouvelles molécules) qui vont être testées par arrimage.
• La fin de la liste affiche d’autres éléments tels que les protéines, leur représentation, les surfaces … L’essentiel de ce qui est utilisé pour le docking est affiché dans l’image.

Suivant le mode de représentation, coté ligands et cofacteurs, nous avons accès aux hydrogènes ou pas, aux aromaticités ou liaisons multiples. Au fur et à mesure de l’avancement du projet, de nouveaux ligands vont être testés. Nous les incorporons progressivement au workspace.  Une bonne pratique est de générer à chaque ajout un nouveau workspace de référence associé à un numéro de version en fin de nom.

5. Conclusion

Il ne reste plus qu’à parler des autres fichiers. La racine inclue un fichier PowerPoint presentation sujet de stage.pptx qui traite de la présentation du stage par l’étudiante associée au projet (avant modification pour éliminer les espaces dans le nom, nous évitons). Nous plaçons ici les documents de référence qui vont être utiles. Si la complexité croit, il peut être nécessaire de mobiliser d’autres répertoires, par exemple si plusieurs acteurs sont impliqués ou si la production de documentation augmente significativement. Dans ces cas, une bonne pratique est de les préfixer par une étiquette correspondant à leur auteur ou à leur thématique, de manière à ce que tous les éléments soient localisés avec dus sens, donc plus facilement retrouvables.