Intégration des flux de travail automatisés de simulation avec la visualisation 3D pour des expériences virtuelles dans le métavers

Résumé

Une méthode généralisée, conforme à FAIR, est présentée aux chercheurs experts du domaine souhaitant intégrer des outils de simulation et de traitement de données dans des flux de travail automatisés pour des expériences virtuelles 3D. Un exemple de neutronique montre la configuration d’une instance Galaxy locale, l’enveloppement d’OpenMC et des outils de conversion de fichiers, le lancement de flux de travail depuis Omniverse et la visualisation des sorties 3D converties.

Résumé

Dans de nombreuses expériences virtuelles, plusieurs logiciels sont utilisés avec différents types de simulations, des outils de pré- et de post-traitement, ainsi que des outils pour visualiser les résultats des expériences — souvent une combinaison des deux. La méthode typique d’intégration est manuelle, avec des solutions sur mesure créées pour chaque domaine applicatif, ce qui est mal évolutif et entrave le partage et la reproductibilité.

Ce protocole démontre le déploiement et l’utilisation d’un système de flux de travail localement conteneurisé. Ensuite, les utilisateurs lancent une instance Galaxy locale via Docker, créent et exécutent un flux de travail de simulation de neutroniques OpenMC, passent les sorties à travers une chaîne d’outils de conversion de formats, et chargent les résultats dans ParaView et NVIDIA Omniverse pour visualisation. Le déploiement conteneurisé favorise la reproductibilité et la portabilité sur toute machine répondant aux exigences matérielles décrites à la Section 1.

Une fois le système en marche, les flux de travail peuvent être réexécutés sur de nouvelles entrées sans reconfiguration manuelle, des codes de simulation supplémentaires peuvent être intégrés en nouveaux outils avec un effort modeste, et les outils peuvent être utilisés dans plusieurs flux de travail et domaines d’application. Cette approche soutient les principes de données FAIR (trouvables, accessibles, interopérables, réutilisables) : les historiques des exécutions capturent toutes les métadonnées de provenance, les flux de travail sont exportables sous forme de fichiers portables et peuvent être partagés directement entre instances Galaxy, et les outils sont emballés dans des conteneurs contrôlés de version pouvant être publiés dans un dépôt public. La scalabilité vers des ressources de calcul haute performance (HPC) ou cloud via le système Pulsar de Galaxy est une extension naturelle de l’architecture décrite ici.

La méthode est démontrée à travers une étude de cas en neutronique de fusion. OpenMC est utilisé pour simuler le transport de neutrons dans une géométrie assistée par ordinateur (CAO) en géométrie directe accélérée Monte Carlo (DAGMC), produisant un résultat du ratio de reproduction du tritium (TBR) et un jeu de données sur la piste de neutrons. Les flux de travail de simulation sont ensuite connectés à NVIDIA Omniverse comme plateforme métavers pour l’invocation et la visualisation.

Introduction

Le métavers industriel combine mondes numériques et physiques pour soutenir la conception, la simulation et la visualisation 3D collaborative de systèmes conçus. Il consistait généralement en de nombreux jumeaux numériques interconnectés de composants pour offrir une vue globale du système. De grandes organisations comme Boeing, BMW, Amazon et bien d’autres adoptent plusieurs approches pour créer des^{métavers 1}. Des systèmes permettant plusieurs chaînes d’outils de simulation et de traitement ont été développés et sont utilisés. Cependant, ces exemples sont généralement soit adaptés à la zone d’application², soit des options^{commerciales 3,4} avec un certain engagement sur des systèmes propriétaires. Certaines alternatives open source pour construire des jumeaux numériques ont été utilisées pour créer certains systèmes, comme Python Flask, dotés de capacités de simulation intégrées. Cependant, ils sont configurés comme des morceaux de code sur mesure pour accomplir des tâches spécifiques liées au modèle⁵ en question. Dans le contexte de ce protocole, la plateforme métavers (NVIDIA Omniverse) fonctionne comme une interface de visualisation 3D et d’interaction de flux de travail : les sorties de simulation sont chargées dans une scène partagée après la fin d’une exécution de workflow, et de nouvelles exécutions peuvent être déclenchées depuis le même environnement. Cela diffère des systèmes numériques en direct où les capteurs en temps réel mettent à jour le modèle en continu ; La méthode présentée ici permet l’exécution par lots de flux de travail et l’exploration post-exécution des résultats. Cependant, cela se fait de manière à soutenir les travaux futurs d’intégration de plus de systèmes dans la plateforme du métavers afin de permettre la création de jumeaux numériques avec des moteurs de workflow en tant que backend computationnel.

Les flux de travail peuvent être définis comme des chaînes d’outils logiciels spécifiant explicitement le flux de données entre eux. Ils permettent d’emballer des codes de simulation existants, des scripts de traitement et d’autres étapes dans un pipeline d’analyse typique, sans modifier leur fonction, mais en permettant plutôt de les configurer et de les reconfigurer avec des entrées et sorties standardisées indépendantes des outils. Les workflows permettent une réplication facile des résultats via le partage d’outils, fournissant également des métadonnées et la provenance des versions utilisées, dans quel ordre et avec quelles entrées. Les outils eux-mêmes peuvent être réutilisés dans de nombreux pipelines de simulation, permettant aux chercheurs de passer moins de temps à mettre en place des simulations et plus de temps à concevoir des expériences et à explorer les résultats. Les systèmes de workflow sont également évolutifs, avec des méthodes de connexion à différentes ressources locales de calcul, cloud et HPC, permettant de nombreux workflows à grande échelle d’être exécutés de manière automatisée sur un matériel^{spécifique 6}.

L’approche manuelle typique est intrinsèquement lente, sujette aux erreurs et difficile à reproduire, dans laquelle un chercheur exécute chaque outil de simulation ou de post-traitement à la main, déplace des fichiers intermédiaires entre environnements et doit documenter les entrées et sorties des exécutions individuelles. À l’inverse, un gestionnaire de workflow formalise le flux de données une fois et le réexécute de manière déterministe. Cela apporte de nombreux avantages par rapport aux pipelines manuels : le même flux de travail peut être exécuté de manière identique sur différentes entrées, en supportant des études de paramètres sans scripting sur mesure ; chaque exécution capture automatiquement toutes les métadonnées de provenance, comblant tout écart de reproductibilité ; et une fois qu’un outil est terminé, son coût de réutilisation dans les flux de travail suivants tombe presque à zéro, à l’exception du temps de calcul. Ces bénéfices ont été quantifiés pour la bioinformatique par Wratten et ^al.7 et pour la protéomique/métabolomique par Perez-Riverol et^{Moreno 8} et Verhoeven et ^al.9.

Historiquement, les flux de travail ont été principalement utilisés dans le domaine de la^{bioinformatique 8,9} avec un grand succès avec de grandes instances publiques telles que le serveur européen^{Galaxy 10,11}, qui en 2022 hébergeait plus de 50 000 utilisateurs, 2 500 outils, exécutait plus de 47 millions de tâches et 260 000 exécutions de workflows. La même pile de moteur de workflow permet l’adaptation à l’échelle sur les ressources HPC et cloud via le système distribué d’exécution des tâches^{Pulsar 6,11}, avec des déploiements opérationnels couvrant 13 points de terminaison Pulsar dans 10 pays européens. Parmi les nombreux gestionnaires de workflow disponibles, y compris Snakemake, Nextflow, Toil et les moteurs compatibles CWL, le moteur de workflow^{Galaxy 11} a été sélectionné pour plusieurs raisons. L’une des principales raisons est son interface mature basée sur navigateur, qui abaisse la barrière d’entrée pour les experts du domaine qui ne travaillent pas principalement en ligne de commande ; il expose une interface complète de programmation d’applications (API) de transfert d’état représentatif (REST) (utilisée dans le présent travail pour faire le pont vers la front-end du métavers) ; Son modèle d’histoire et d’emplois capture la provenance sous une forme facile à faire reconnaître auprès de collaborateurs non spécialistes ; et il supporte un déchargement HPC transparent via le système Pulsar mentionné plus haut (bien que cela ne soit pas abordé dans la section protocole de cet article). L’approche décrite dans cet article, cependant, est en principe indépendante du moteur de workflow : des intégrations équivalentes pourraient être construites sur des moteurs alternatifs. La contribution de ce travail n’est pas le gestionnaire de flux de travail lui-même, mais la traduction d’un gestionnaire de flux de travail polyvalent initialement développé pour la bioinformatique vers d’autres domaines (avec l’exemple spécifique de la neutronique de fusion ici), et son intégration avec une plateforme industrielle-métavers (NVIDIA Omniverse), au sein d’une pile entièrement conteneurisée et localement déployable, appliquée à des expériences virtuelles 3D.

Enfin, la conteneurisation permet le partage de nombreux logiciels en empaquetant le code avec le système d’exploitation et toutes les dépendances nécessaires pour s’exécuter. Ces environnements évitent les problèmes de dépendances manquantes et la contrainte liée à l’installation de certains codes de simulation. Ils sont similaires dans leur fonction aux machines virtuelles mais beaucoup plus légers et plus portables. Ils augmentent considérablement la partageabilité et la reproductibilité des logiciels de type « reproductibilité ». Dans cette méthode, le gestionnaire de flux de travail et les outils individuels s’exécutent dans des conteneurs Docker¹² , augmentant la compatibilité avec différents systèmes d’exploitation tant que l’utilisateur peut exécuter des conteneurs.

Ce protocole est destiné aux chercheurs experts du domaine, par exemple les ingénieurs en neutronique de fusion, les analystes en dynamique des fluides computationnelle ou les praticiens des éléments finis, qui maîtrisent les outils de simulation de leur propre domaine mais n’ont pas encore utilisé de gestionnaire de flux de travail ou de déploiement basé sur conteneurs. On suppose une familiarité avec un seul code de simulation et un fonctionnement de base en ligne de commande ; la familiarité avec Galaxy ou l’Omniverse ne l’est pas. Les lecteurs débutants en conteneurisation doivent consulter la documentation officielle Docker (https://docs.docker.com/) ou la formation d’introduction disponible à : https://uomresearchit.github.io/docker-introduction/ avant de suivre la Section 1 ; Les commandes de base nécessaires pour exécuter le logiciel sont toutes contenues dans le protocole.

Le reste de ce rapport couvrira la configuration et l’utilisation du système déployable localement. Ensuite, il suivra des étapes pour développer de nouveaux outils pour le système et une méthode pour lier d’autres packages externes au moteur de workflow, comme une plateforme métavers. Tout au long du rapport, une simulation de neutronique utilisant OpenMC¹³ sert d’étude de cas. OpenMC a été choisi car il démontre le pipeline complet CAO-simulation-puis-visualisation de sortie qui motive l’architecture du workflow. Un fichier de géométrie et un fichier de configuration servent d’entrées structurées ; la simulation de transport de neutrons de Monte Carlo produit une métrique scalaire (le ratio de reproduction du tritium, TBR) qui peut être comparée à une plage de valeurs connue, ainsi qu’un ensemble de données spatialement résolu sur la piste de neutrons pouvant être traité et présenté dans un format visualisable pour le rendu 3D dans l’application du métavers.

Protocole

REMARQUE : Un aperçu de la configuration locale du moteur de workflow, de la construction, du lancement du workflow et des résultats de visualisation est présenté dans les figures 1, 2, 3, 4, 5, 6, 7 et 8. Les fichiers du dépôt nécessaires à l’exécution du protocole sont fournis dans le Fichier Supplémentaire 1.

1. Installation

1. Exigences
   REMARQUE : Cette méthode a été testée sur la dernière version de Support Long Term (LTS) d’Ubuntu, la 22.04.1 LTS. D’autres versions d’Ubuntu et d’autres distributions peuvent fonctionner, mais elles n’ont pas été testées ici. Il fonctionne également sur des systèmes Windows, utilisant Windows Subsystem for Linux (WSL) comme backend Docker.
   1. Utilisateurs Windows : Téléchargez WSL et configurez-le, car c’est une exigence pour Docker.
   2. Téléchargez Docker puis vérifiez en exécutant :
      `Docker gère Hello-World »
      qui devrait afficher un message de bienvenue.
   3. Téléchargez le lanceur NVIDIA Omniverse et l’une des applications Omniverse via le lanceur.
      REMARQUE : Le rendu ray-tracé en temps réel de NVIDIA Omniverse nécessite un GPU de classe RTX. Les utilisateurs sans ce matériel peuvent toujours exécuter le flux de travail complet via la Section 2 et inspecter les sorties intermédiaires .vtk / .vtp dans ParaView (voir Discussion). Ces utilisateurs peuvent sauter la Section 3, car celle-ci ne concerne que la plateforme du métavers ; Les méthodes utilisées pour intégrer le moteur de workflow ici peuvent être utiles si vous vous connectez à d’autres plateformes du métavers.
      Ce protocole utilise l’application Omniverse Code, mais les autres applications Omniverse devraient être globalement similaires. Bien que ce ne soit pas indispensable, ParaView peut être utilisé pour visualiser certains des fichiers intermédiaires produits par les outils de ce protocole.
2. Dépôt
   1. Clonez le dépôt contenant tous les fichiers et scripts nécessaires pour l’instance locale du moteur de workflow et les outils décrits dans cet article avec :
      'Va https://github.com/williamjsmith15/galaxy-omniverse-example.git'
   2. Ajoutez un e-mail administrateur à la liste des utilisateurs administrateurs.
      REMARQUE : Cela donnera les privilèges administrateur nécessaires pour certaines fonctionnalités du moteur de workflow et se trouve dans la section admin_users du fichier galaxy-config/galaxy.yml (voir https://github.com/williamjsmith15/galaxy-omniverse-example/blob/master/galaxy-config/galaxy.yml).
   3. Renomme le fichier default.json.template en default.json. Ce fichier se trouve à omni_exts/omni.galaxy.example/omni/galaxy/example/default.json.template.
      REMARQUE : Cela permettra de le lire par l’extension de la plateforme métavers et d’ajouter et de maintenir des paramètres personnels entre les chargements — d’autres modifications seront apportées après la configuration de l’instance galaxy.
3. Lancement du serveur local du moteur de workflow
   1. Lancez l’instance du moteur de workflow en exécutant le fichier start-galaxy.sh au niveau supérieur du dépôt :
      './start-galaxy.sh'
      Si le fichier ne s’exécute pas ici, il peut devoir être rendu exécutable si les permissions ont changé dans le clone du référentiel. Cela peut se faire en courant :
      'chmod a+x start-galaxy.sh'
      REMARQUE : Les utilisateurs Windows doivent le faire via leur terminal WSL. Cela télécharge les fichiers concernés et lance l’instance du moteur de workflow, qui peut être consultée à http://localhost:8080 dans n’importe quel navigateur fonctionnant sur la même machine. Cela devrait afficher la page illustrée à la Figure 1 ; Sinon, attendez et rafraîchissez — l’instance du moteur de workflow peut prendre un certain temps à se lancer (surtout la première fois).
      1. En général, pour voir les modifications apportées dans le dépôt sur l’instance du moteur de workflow, exécutez './restart-galaxy.sh' ou './stop-galaxy.sh', puis relancez le script.
4. Configuration des plateformes du métavers
   1. Ouvrez l’application après avoir téléchargé le lanceur et l’application (pour cet exemple, Omniverse Code).
   2. En haut à gauche de la fenêtre, cliquez sur l’onglet Extensions (dans d’autres applications, cela se trouve sous Fenêtre | Extensions).
   3. Dans la fenêtre des extensions , cliquez sur le bouton réglages gris ; Cela ouvrira une fenêtre avec quelques annuaires déjà remplis. Ajoutez un autre chemin qui pointe vers le dossier omni_exts en cliquant sur le bouton vert plus et un chemin qui aura le format : « /exemple-omniverse-galaxie/omni_exts » ; voir la Figure 2 pour plus de détails.
   4. Cherchez une nouvelle entrée appelée « EXEMPLE OMNI GALAXY » dans la colonne de gauche sous l’onglet TIERS PARTI. Activez le curseur de cette extension, et attendez que la fenêtre d’extension apparaisse.
   5. Sélectionnez la case autoload pour charger automatiquement l’extension à chaque lancement de l’application.
      REMARQUE : Les modifications apportées aux fichiers d’extension doivent être automatiquement maintenues lors de la sauvegarde du fichier, car Omniverse permet le rechargement à chaud des extensions
5. Création de compte dans un moteur de workflow et lien vers le Metaverse
   1. Dans l’instance du moteur de workflow, créez un compte en cliquant sur le bouton Connexion ou Inscription dans la barre supérieure, puis Inscrivez-vous ici, et remplissez les informations en utilisant l’adresse e-mail ajoutée à l’étape 1.2.2 pour créer un compte avec accès administrateur.
   2. Générez une clé API pour permettre à l’API de communiquer avec le moteur de workflow. Va dans le menu déroulant Utilisateur dans la barre du haut | Préférences | Gérer la clé API. Créez une clé et copiez-la.
   3. Une fois la clé générée, ajoutez-la au fichier default.json créé à l’étape 1.2.3 sous le champ « galaxy_api_key » dans les guillemets vides.
      ATTENTION : Ce fichier contiendra désormais une clé API. Cette clé API peut être utilisée pour exécuter des tâches et accéder aux données sur le compte associé. Cela ne devrait pas poser de problème dans un déploiement local où il n’y a pas de domaine public ou d’adresse IP ; Ce fichier doit toujours être considéré comme secret et donc ne pas être partagé ni engagé dans un dépôt public (le fichier est listé par défaut dans le .gitignore pour lutter contre cela).
   4. Relance l’application de la plateforme métavers pour rafraîchir les modifications apportées dans le fichier par défaut.
      REMARQUE : La clé API peut également être ajoutée directement dans la fenêtre d’extension via le menu déroulant des paramètres serveur, bien que cela ne persiste pas entre les sessions.

2. Exécution des tâches sur le moteur de workflow

1. Outils simples
   REMARQUE : Les outils uniques permettent d’exécuter et d’inspecter individuellement des étapes de traitement ou de simulation, ce qui est utile pour vérifier que les entrées sont correctement formatées et qu’un outil fonctionne comme prévu avant de les intégrer dans un flux de travail. Les fichiers de test référencés ci-dessous, dagmc.h5m (la géométrie CAO DAGMC) et openmc_config.json (la configuration de simulation), se trouvent dans le répertoire test_files du dépôt cloné.
   1. Téléversez les fichiers d’entrée nécessaires en cliquant sur Télécharger les données dans la colonne de gauche et sélectionnez soit Choisir les fichiers locaux , soit en glissant-déposer depuis un explorateur de fichiers dans cette fenêtre. Téléchargez le fichier dagmc.h5m (fichier CAO) et openmc_config.json (fichier de configuration), puis cliquez sur le bouton Start pour télécharger dans l’historique actuel. Les deux fichiers apparaîtront en vert dans le panneau Historique à droite une fois le téléchargement terminé.
   2. Sélectionnez le menu déroulant Outils complexes dans la colonne de gauche de la page d’atterrissage, puis l’outil de simulation neutronique OpenMC .
   3. Maintenant, sur la page spécifique à l’outil, sélectionnez les entrées des fichiers téléchargés à l’étape 2.1.1 et sélectionnez le fichier CAO comme jeu de données dagmc.h5m et le fichier de configuration comme jeu de données openmc_config.json .
   4. Cliquez sur le bouton Exécuter . Deux nouveaux fichiers (TBR et Tracks) apparaîtront dans le panneau Historique à droite de l’écran. Ils deviennent orange en cours d’exécution et verts lorsqu’ils sont terminés et réussis, le rouge indique une panne d’outil. Voir la section 4 pour les étapes de débogage.
   5. La valeur TBR (ratio de reproduction du tritium) peut être visualisée pour vérifier que le cas test a été exécuté avec succès. Cliquez sur la sortie de la lecture à lire pour développer, puis sur l’icône du graphique, et enfin sur l’éditeur. Cela fera apparaître le résultat de la lecture à lire, qui devrait être autour de 0,76 (il s’agit d’une méthode statistique, et la configuration ici utilise une petite taille d’échantillon pour la vitesse de simulation, donc les résultats varient).
      REMARQUE : La valeur de la TBR est stochastique ; La valeur de 0,76 peut varier de ±0,01, ce qui reflète un nombre délibérément petit de particules (5 lots de 1 000 particules) choisi pour des flux de travail rapides en exemple. Pour réduire la plage de valeurs, augmentez le nombre de lots et de particules sous le champ paramètres du fichier openmc_config.json avant de relancer. En guise de référence pour une géométrie simple telle que celle présentée ici, 50 lots de 10 000 particules devraient réduire la dispersion des valeurs de TBR lors des exécutions suivantes, au prix d’un temps d’exécution plus long.
   6. D’autres outils peuvent être exécutés sur la sortie Tracks du workflow pour post-traiter les résultats. Exécutez l’outil Tracks h5 vers vtp sur la sortie Tracks puis l’outil CAD h5m vers vtk sur le fichier d’entrée dagmc.h5m . Ces deux produits produiront une seule sortie, tracks_0.vtp et dagmc.vtk, qui les convertira en un format plus facilement visualisable.
   7. Les sorties produites à l’étape précédente peuvent être téléchargées depuis l’instance (en cliquant sur la sortie puis sur l’icône de sauvegarde) puis visualisées dans ParaView¹⁴ pour voir les traces de neutrons simulées.
   8. Pour visualiser les résultats dans ParaView, importez les sorties téléchargées tracks_0.vtp et dagmc.vtk . Celles-ci apparaîtront sur le côté gauche de la fenêtre. Cliquez soit sur l’icône Œil à côté des fichiers importés, soit sur le bouton Appliquer ci-dessous dans la fenêtre des propriétés pour visualiser la sortie. Cela devrait être similaire à ce que l’on voit à la Figure 7.
2. Flux de travail
   REMARQUE : Un flux de travail encode un pipeline de traitement complet sous forme de graphe orienté d’outils avec des entrées et sorties déclarées. Une fois défini, le même flux de travail peut être réexécuté sur n’importe quel ensemble de fichiers d’entrée sans reconfigurer manuellement chaque outil, et tous les historiques d’exécution ainsi que les métadonnées de provenance sont capturés automatiquement.
   1. Cliquez sur Flux de travail dans la barre de navigation en haut, puis sur Créer en haut à droite. Saisissez un nom et une description pour le flux de travail (n’importe quoi fera l’affaire), puis cliquez sur Créer à nouveau.
   2. Ajoutez trois outils au flux de travail, développez les sections concernées dans le menu Outils et ajoutez les outils utilisés dans la section 2.1 : OpenMC Neutronique Simulation, CAD h5m vers vtk et Pistes h5 vers vtp.
   3. Définissez le flux de données entre les outils. Faites glisser les outils dans l’espace de travail en cliquant et en glissant sur la barre supérieure bleu foncé de chacun. Connectez la sortie Tracks (h5) de l’outil de simulation de neutronique à l’entrée tracks.h5 de l’outil h5 vers vtp. Faites cela en cliquant et en glissant de la flèche de sortie à la flèche de l’entrée.
   4. Définissez les ensembles de données d’entrée au niveau du flux de travail. Dans la section Entrées des outils, cliquez deux fois sur Jeu de données d’entrée pour créer deux nœuds d’entrée. Renomme l’un pour le fichier de configuration et l’autre pour l’entrée CAO en cliquant sur l’étape puis en changeant le champ Étiquette dans le menu des propriétés de droite.
   5. Relier le fichier de configuration et le fichier CAO aux entrées de l’outil de simulation de neutronique, et le fichier CAO à l’outil h5m vers vtk, en suivant le motif de la Figure 3.
   6. Sauvegardez le flux de travail en utilisant l’icône de sauvegarde en haut à droite.
   7. Pour exécuter le workflow, cliquez sur l’onglet Workflow dans la barre du haut comme précédemment, puis cliquez sur l’icône lecture du workflow à exécuter. Ensuite, sélectionnez les entrées comme dans l’étape 2.1.2, identique à l’exécution d’un outil, et cliquez sur Exécuter le flux de travail.
   8. Attendre que le flux de travail s’exécute, puis les sorties peuvent être comparées aux étapes 2.1.5 et 2.1.8 ; Celles-ci devraient être très similaires (encore une fois, notez la variation statistique de ces étapes). Le flux de travail a bien fonctionné lorsque toutes les sorties de l’Historique sont passées au vert. Il devrait y avoir (en plus des ensembles de données d’entrée) quatre ensembles de données présents ici : TBR, Tracks, dagmc.vtk et tracks_0.vtp.
   9. Au fur et à mesure que le flux de travail a été exécuté, certains utilisateurs peuvent vouloir pouvoir voir la provenance et les métadonnées capturées de l’invocation (exécution) du workflow. Cela peut être réalisé en naviguant vers Utilisateur dans la barre supérieure | Invocations de workflow. Cela donne la liste de tous les flux de travail exécutés par l’utilisateur, cliquer sur la flèche descendante sur le flux de travail qui vous intéresse, puis télécharger le fichier JSON des métadonnées en cliquant sur le bouton Télécharger l’objet BioCompute . Cela contient la provenance des outils/workflows utilisés, des entrées utilisées, etc.
      REMARQUE : Le moteur de workflow enregistre également un historique complet des exécutions pour chaque exécution de workflow, incluant les sommes de contrôle des fichiers d’entrée, les versions des outils et les valeurs des paramètres. Pour télécharger l’enregistrement de provenance d’une exécution, ouvrez le panneau Historique , cliquez sur le menu (flèche vers le bas) en haut à droite, puis sélectionnez Exporter l’historique dans le fichier. L’archive exportée contient tous les ensembles de données et un enregistrement lisible par machine des étapes qui les ont produites.
      La sauvegarde de la provenance ou des historiques générés par le moteur de workflow peut être automatisée via l’API discutée à la Section 5.1 ; cependant, cela ne sera pas détaillé dans ce protocole.
3. Flux de travail plus complexe
   REMARQUE : Ce flux de travail étend la Section 2.2 en ajoutant des étapes de post-traitement qui produisent des fichiers Universal Scene Description (USD) nécessaires à la visualisation sur la plateforme du métavers. Parce qu’aucun outil unique ne convertit directement de DAGMC (.h5m) ou VTK (vtp) en USD, le pipeline achemine les données à travers deux chaînes de conversion en plusieurs étapes : la géométrie CAO suit un pipeline H5M, STL, OBJ, USD, et les pistes neutrons suivent H5, VTP, OBJ, USD.
   1. Suivez les étapes pour mettre en place un flux de travail, comme montré dans la section 2.2, en suivant le flux de travail illustré à la Figure 4.
   2. Définissez les deux entrées au niveau du workflow comme à l’étape 2.2.4, en les nommant CAD, DAGMC et Config File.
   3. Ajoutez l’outil de simulation de neutronique OpenMC et connectez les entrées DAGMC CAD et Config File à ses entrées correspondantes comme à l’étape 2.2.3.
   4. Créez la chaîne de conversion en neutronique. Ajoutez les pistes h5 à vtp, vtp à obj, et obj à USD, puis connectez les sorties de chacune aux entrées du suivant, en suivant la disposition dans la branche inférieure de la Figure 4.
   5. Créez la chaîne de conversion CAO. Ajoutez les outils h5m à STL, STL à OBJ, et OBJ à USD, puis reconnectez à nouveau les sorties de chacun aux entrées du suivant, en suivant la disposition dans la branche supérieure de la Figure 4.
   6. Sauvegardez le flux de travail, qui est désormais prêt à être utilisé sur la plateforme métavers via l’extension de la Section 3.
      REMARQUE : Ces étapes supplémentaires montrent aux utilisateurs comment les flux de travail et outils peuvent être partagés, permettant la reproductibilité et l’accessibilité des données et méthodes utilisées pour générer des résultats.
   7. Exportez le flux de travail en fichier portable en allant dans Flux de travail dans la barre supérieure, en cliquant sur le menu (flèche vers le bas) et en sélectionnant Télécharger. Le gestionnaire de workflow sauvegarde un fichier JSON .ga , qui peut ensuite être partagé et utilisé par toute personne possédant les mêmes outils sur son instance du moteur de workflow. Cela peut être importé via Workflow dans la barre supérieure | Importer.
   8. Partagez les outils en validant le dossier galaxy-tools/ du dépôt cloné sur un hôte public de contrôle de version. Demandez aux collaborateurs de cloner cela pour accéder à tous les outils conteneurisés, en les exécutant de la même manière que sur l’appareil local de l’éditeur.
      REMARQUE : Les instances publiques du gestionnaire de workflow peuvent être configurées, ce qui contourne le partage manuel des fichiers de workflow et outils entre déploiements locaux. Dans ces cas, les outils sont accessibles à tous les utilisateurs, et les flux de travail ainsi que les historiques peuvent être rendus publics à tous les autres utilisateurs. Cela dépasse le cadre de ce protocole, mais plus d’informations peuvent être trouvées dans le réseau officiel Galaxy Training pour obtenir un déploiement permanent : https://training.galaxyproject.org/training-material/topics/admin/tutorials/ansible-galaxy/tutorial.html ou la pile docker compose fournie dans le dépôt peut être déployée telle quelle sur un serveur puis acheminée via un proxy ou un moyen similaire pour la rendre accessible au public.

3. Exécution d’un flux de travail depuis la plateforme du métavers

1. Lancement du flux de travail
   1. Dans la fenêtre d’extension de la plateforme métavers, cliquez sur Obtenir des flux de travail (annotation 2, Figure 5). Un menu déroulant s’affichera avec tous les flux de travail disponibles sur le compte moteur de workflow associé à la clé API stockée dans default.json. Si ce n’est pas le cas, vérifiez que la clé API a été correctement sauvegardée dans le fichier JSON, puis relancez l’application de la plateforme métaverse pour vous assurer qu’elle récupère la clé.
   2. Sélectionnez le flux de travail complexe pour la liste, puis cliquez sur Obtenir des entrées (annotation 4, figure 5). Les champs d’entrée définis dans le flux de travail (Étape 2.3.2) apparaîtront et devront porter le même nom.
   3. Pour chaque entrée basée sur un fichier, cliquez sur Select File et utilisez la fenêtre contextuelle de l’explorateur de fichiers pour sélectionner le fichier local correspondant : dagmc.h5m pour l’entrée DAGMC CAO et openmc_config.json pour l’entrée Config File .
   4. Cliquez sur Lancer le flux de travail (annotation 6, Figure 5). Un message de confirmation de lancement sera affiché dans la section Informations (annotation 7). Une fois le flux de travail terminé, des messages supplémentaires confirmeront que les fichiers de sortie ont été sauvegardés et que l’exécution est terminée.
      REMARQUE : L’avancement des tâches du workflow peut être suivi sur l’interface web du moteur de workflow à http://localhost:8080 en naviguant dans Admin | Jobs. L’accès administrateur est requis (voir l’étape 1.2.2).
2. Visualisation des résultats
   REMARQUE : À la fin de chaque exécution de workflow, le système télécharge automatiquement les fichiers de sortie du moteur de workflow vers un répertoire de sortie local. Le chemin de sauvegarde est contrôlé par la touche output_dir dans le fichier default.json de l’extension. Chaque exécution est stockée dans un dossier horodaté, permettant ainsi de distinguer les sorties par l’extension. S’il y a des problèmes de visualisation sur la plateforme du métavers, les fichiers peuvent être consultés dans ces dossiers et consultés manuellement pour voir si le problème vient du moteur de workflow.
   1. Dans la plateforme du métavers, développez la section Gestionnaire de fichiers (annotation 1, Figure 6) et cliquez sur Rafrapîchir (annotation 2). Cela récupère la liste des exécutions de flux de travail réalisées enregistrées dans le répertoire local.
   2. Dans le menu déroulant Dossiers (annotation 3, Figure 6), sélectionnez le dossier pour l’exécution de workflow en cours (confirmez que c’est le seul actuellement présent) et cliquez à nouveau sur Rafraîchir pour remplir le menu déroulant Fichiers avec les sorties de cette exécution.
   3. Sélectionnez un fichier dans le menu déroulant Fichiers (annotation 4, Figure 6 ; seuls les fichiers .usd, .txt, .json et .out sont actuellement pris en charge) puis cliquez sur Tirer fichier (annotation 5). Les fichiers textuels sont affichés dans le panneau Infos , les fichiers USD sont ajoutés à la scène actuelle et doivent être visualisés dans la fenêtre principale.
   4. Pour aligner la géométrie importée avec la convention de coordonnées d’Omniverse, ouvrez le panneau Stage à droite, sélectionnez les deux objets de workflow importés, et dans le panneau Propriétés juste en dessous, réglez Rotation X à −90°. Cela corrige le décalage entre la convention z-up utilisée par les outils d’exportation USD et la convention y-up d’Omniverse. Appliquez cette rotation à la fois au fichier USD CAD et au fichier USD des pistes ; l’état attendu de la fenêtre de vue après alignement est montré à la Figure 8.
   5. Enfin, pour obtenir plus de contraste entre les pièces, des matériaux peuvent être assignés. Cela se fait en ouvrant l’onglet Matériaux en bas de l’application, en sélectionnant un matériau, puis en glissant et déposant sur la géométrie dans la vue Scène dans la colonne de droite. Faites cela pour les deux géométries importées afin d’augmenter le contraste entre elles.

4. Ajout de nouveaux outils

REMARQUE : Cette section décrit le processus de développement pour créer et déployer de nouveaux outils de workflow. Cela nécessite l’accès au système de fichiers du dépôt, ainsi qu’un accès administrateur au moteur de workflow pour le débogage. Les utilisateurs qui n’ont besoin que d’exécuter des outils et flux de travail existants, ou de créer des flux de travail, n’ont pas besoin de suivre cette section.

1. Processus général
   1. Développez et testez le script de simulation ou de traitement indépendamment du moteur de workflow avant de l’envelopper. Le wrapper des outils appelle un script de travail existant, il n’est pas recommandé d’implémenter une nouvelle logique lors du développement d’un outil.
   2. Préparez l’environnement d’exécution du script en créant une image Docker qui inclut toutes les dépendances à l’exécution (bibliothèques, binaires, fichiers de données, etc.) requises par le script.
      REMARQUE : Tous les outils exemples de ce protocole utilisent des conteneurs Docker comme environnement d’exécution. Les environnements Conda sont également pris en charge par le moteur de workflow mais ne sont pas présentés ici. Plus d’informations sur Docker sont disponibles via la documentation officielle, ou un bon cours d’introduction est disponible ici : https://uomresearchit.github.io/docker-introduction/ .
   3. Créez un fichier de définition d’outil XML qui déclare l’environnement d’exécution (Docker dans ce cas), la commande pour invoquer le script, ainsi que les entrées, sorties et métadonnées des outils pour affichage dans l’interface du moteur de workflow.
   4. Une fois l’emballage créé, placez le XML et tous les scripts dans un nouveau dossier galaxy-tools// dans le référentiel. Ajoutez une nouvelle entrée pour l’outil dans galaxy-tools/tool_conf.xml sous les balises
      appropriées, en pointant vers le chemin relatif du fichier XML nouvellement créé.
      REMARQUE : Assurez-vous que ce nom de fichier est copié exactement, car c’est une erreur courante lors du déploiement de nouveaux outils. Si l’entrée tool_conf.xml contient un chemin incorrect ou si le fichier XML présente une erreur de syntaxe, l’instance du moteur de workflow ne démarrera pas. Pour inspecter les journaux du conteneur de workflow à la recherche de messages d’erreur, exécutez ce qui suit depuis la racine du dépôt :
      « docker compose logs galaxy »
      Les erreurs d’analyse XML apparaissent sous forme de lignes de l’outil de chargement ERROR du formulaire
   5. Redéployez le moteur de workflow pour charger le nouvel outil en exécutant le script de redémarrage depuis la racine du dépôt : ./restart-galaxy.sh.
   6. Confirmez que l’outil a été correctement enregistré. Naviguez jusqu’à http://localhost:8080, localisez l’outil dans le panneau Outils et cliquez dessus pour vous assurer que toutes les entrées apparaissent comme prévu. Si l’outil est absent, suivez la note ci-dessus pour le débogage, et s’il y a encore des erreurs, vérifiez la syntaxe du XML de l’outil lui-même, car cela peut également entraîner des erreurs de déploiement.
   7. Exécutez le nouvel outil comme avant, mais avec des entrées déjà testées. Les sorties devraient passer au vert dans le panneau Historique
   8. Si les outils échouent, alors en tant qu’administrateur, cliquez sur la sortie raté (rouge) et cliquez sur l’icône Infos . Cela montre une page de sortie détaillée et affiche les flux stdout et stderr. Ces éléments peuvent être développés pour obtenir plus d’informations sur le débogage de l’outil.
2. Outils simples
   REMARQUE : Les outils 1 à 5 illustrent des motifs d’enroulement de plus en plus complexes. Le fichier XML et tous les scripts de chaque outil se trouvent dans le sous-répertoire galaxy-tools/simple// correspondant du dépôt. Déployez et exécutez chaque outil en suivant les étapes 4.1.4–4.1.5 et la section 2.1.
   Outil 1 – Exécuter une commande simple
   1. Regarde le fichier galaxy-tools/simple/1/1.xml . L’élément exigences spécifie un environnement d’exécution Linux. L’élément de commande contient la commande d’écho à exécuter.
   2. Exécutez l’outil 1 depuis l’interface du moteur de workflow sans qu’aucun fichier d’entrée ne soit requis. Comme il n’y a pas non plus de fichiers de sortie définis, en tant qu’Admin, allez sur la page Admin, Jobs puis cliquez sur l’icône Information pour voir les flux stdout et stderr, qui est identique à l’étape 4.1.8. Le flux stdout ne doit contenir que la chaîne « hello world » de la commande dans le fichier XML.
      Outil 2 – Utilisation de l’entrée textuelle
   3. Regardez le fichier galaxy-tools/simple/2/2.xml . Il y a maintenant une entrée dans le champ d’entrée, avec un élément param type ="text » et la section commande fait désormais référence à la variable d’entrée par l’étiquette de nom.
   4. Utilisez l’outil 2 comme avant ; Cette fois, donnez à l’outil une entrée de ficelle. Cela peut être tout ce que l’utilisateur souhaite. Voyez la sortie comme dans l’étape 4.2.2, et la sortie stdout doit être la chaîne fournie par l’utilisateur dans l’entrée de l’outil.
      Outil 3 – Utilisation d’une entrée basée sur un fichier
   5. Encore une fois, regardez le fichier d’outils ; Désormais, au lieu d’une entrée de chaîne de caractères, le paramètre d’entrée utilise un tag type="data », qui permet l’utilisation d’un fichier. Ceci est référencé dans la section commande comme un chemin de fichier, toujours en utilisant le nom du paramètre d’entrée.
   6. Créez un fichier .txt à l’aide d’un éditeur de texte local, sinon exécutez :
      « Echo « hello world from a file » > test_files/input.txt'
      depuis le dossier racine du dépôt pour générer l’entrée d’exemple.
   7. Téléverser le fichier de .txt créé comme à l’étape 2.1.1, puis exécuter l’outil 3 comme précédemment, en sélectionnant le fichier .txt téléchargé en entrée. Encore une fois, regardez le stdout de la même manière, et le contenu du fichier .txt devrait s’y afficher. Si vous utilisez la commande ci-dessus, la sortie devrait être « hello world from a file ».
      Outil 4 – Écrire des sorties dans un fichier
   8. Examinez galaxy-tools/simple/4/4.xml. Une section de sorties déclare désormais un fichier de sortie nommé qui peut être référencé dans la section commandes .
   9. Exécutez l’outil comme avant avec l’entrée .txt , mais maintenant, au lieu de voir la sortie en tant qu’admin, celle-ci peut être vue par l’utilisateur habituel dans ce panneau d’Historique , et lors d’une exécution réussie, cela passera au vert et pourra être téléchargé / consulté dans le moteur de workflow comme détaillé dans les sections précédentes.
      Outil 5 – Exécuter des scripts dans les outils
   10. Examinez galaxy-tools/simple/5/5.xml et le script python associé galaxy-tools/simple/5/5.py. Dans le XML, la commande fait référence au script Python du répertoire outil, et la section des exigences fait désormais référence à une image Python car Python est nécessaire pour exécuter le script.
   11. Déploie et exécute l’outil de la même manière, et il devrait se comporter comme l’outil 4 (étape 4.2.9), sauf que cette fois il exécute un script plutôt que la commande directement.
3. Exemple d’outil complexe
   REMARQUE : Cette section documente le développement de l’outil de neutronique en tant qu’exemple fonctionnel du modèle décrit à la Section 4.1. Les fichiers pertinents sont dans galaxy-tools/complex/openmc/. Le même schéma se généralise à tout code de simulation ou de traitement.
   1. Développez le script d’exécution pour la simulation. Pour cet exemple, le script run galaxy-tools/complex/openmc/openmc_run.py analyse un fichier de configuration (openmc_config.json), écrit le fichier de paramètres neutroniques et exécute la simulation. Testez le script directement depuis la ligne de commande avant de l’emballer dans une image Docker.
   2. Construis l’environnement d’exécution Docker en utilisant le fichier Docker à galaxy-tools/complex/openmc/Dockerfile. Cela prolonge l’image publique avec quelques paquets supplémentaires. Construisez et identifiez localement ou référencez-le depuis un registre de conteneurs.
   3. Créez le wrapper XML galaxy-tools/complex/openmc/openmc.xml, en déclarant l’image Docker de l’étape 4.3.2 dans la section exigences . La commande à exécuter avec les fichiers d’entrée et de sortie (comme dans l’exemple de la Section 4.2) doit également être définie.
   4. Déployez l’outil comme indiqué aux étapes 4.1.4-4.1.7, puis utilisez les entrées de test utilisées dans la Section 2 pour vous assurer que l’outil fonctionne correctement.
      REMARQUE : Les autres outils de l’instance (pistes h5 vers vtp, CAD h5m vers vtk, h5m vers stl, stl vers obj, vtp vers obj, obj vers USD) sont des convertisseurs de formats de fichiers suivant le même schéma de développement. Leurs fichiers XML sont dans le répertoire galaxy-tools/complex/ et peuvent servir d’exemples de référence supplémentaires.

5. Connexion des flux de travail au Métavers

REMARQUE : Cette section fournit des documents de référence pour les développeurs décrivant l’intégration API du moteur de workflow et l’architecture de l’extension de la plateforme métavers. Les utilisateurs qui n’ont besoin que d’exécuter des flux de travail depuis la plateforme métavers doivent suivre la Section 3 et ne pas avoir besoin de lire cette section. Les développeurs souhaitant connecter une application front-end différente au moteur de workflow doivent commencer par la Section 5.1.

1. API du moteur de flux de travail
   REMARQUE : Galaxy expose une API RESTful. La bibliothèque Python Bioblend fournit un wrapper de niveau supérieur autour de cette API et constitue la base de tous les scripts d’assistance utilisés dans ce protocole. Bioblend est installé automatiquement dans les environnements d’exécution Docker pertinents fournis dans le dépôt.
   1. Importez Bioblend et établissez une connexion au moteur de workflow en cours d’exécution en instanciant un objet GalaxyInstance avec l’adresse serveur et la clé API de l’étape 1.5.2. En Python dans un environnement avec Bioblend installé :
      `from bioblend.galaxy import GalaxyInstance
      gi = GalaxyInstance(url='http ://localhost :8080', key=)'
      REMARQUE : Cela ne fonctionnera que pour les déploiements locaux ; si le moteur de workflow est déployé sur une machine distante, remplacez l’hôte local par l’adresse et le port de l’instance configurée.
   2. Utiliser les fonctions d’assistance dans galaxy-api/helper_functs.py pour effectuer des opérations courantes : lister les flux de travail disponibles (get_workflows), récupérer les définitions d’entrée des flux de travail (get_inputs) et lancer un flux de travail avec des fichiers d’entrée spécifiés (launch_workflow). Référez-vous aux docstrings en ligne dans ce fichier pour les signatures de fonctions et les types de retour attendus.
   3. Prolonger la helper_functs.py avec d’autres fonctions selon l’application. L’API de référence complète est disponible à https://bioblend.readthedocs.io.
2. Liaison des flux de travail vers le métavers
   REMARQUE : Cette section ne décrit que l’architecture de l’extension de la plateforme métavers afin que les développeurs puissent l’adapter à différents flux de travail, à des types de fichiers supplémentaires ou à des plateformes alternatives du métavers.
   1. Ouvrez le point d’entrée principal de l’extension dans omni_exts/omni.galaxy.example/. Cette extension utilise l’extension^{de base Omniverse 15} comme point de départ. Il ajoute ensuite toutes les fonctionnalités du fichier API Python des fonctions d’assistance décrit à l’étape 5.1.2 et fournit une interface graphique pour interagir avec les flux de travail.
   2. Lorsque les flux de travail sont lancés, les données qu’ils produisent sont automatiquement téléchargées depuis le moteur de workflow et stockées localement, ce qui permet de les visualiser dans la plateforme métavers. Cela permet également d’enregistrer et de rendre accessibles les métadonnées générées lors de l’exécution du workflow, fournissant ainsi la provenance des données de simulation.
   3. Cette implémentation utilise la bibliothèque native omni.ui d’Omniverse pour construire l’interface. L’extension principale se trouve dans le dossier d’extensions, et l’implémentation principale de l’interface se trouve dans le fichier omni_exts/omni.galaxy.example/omni/galaxy/example/window.py .

Résultats

Si les simulations sont exécutées avec les entrées fournies dans le dépôt git, les résultats suivants doivent être obtenus :

À la réussite de l’étape 2.1.3, les ensembles de données de sortie TBR et Pistes apparaîtront en vert dans le panneau Historique , indiquant une exécution réussie. Une valeur représentative de TBR utilisant le fichier de configuration fourni (5 lots de 1 000 particules) est d’environ 0,7...

Discussion

Il y a quelques étapes cruciales dans le protocole. La plupart concernent la configuration initiale de l’instance du moteur de workflow, telles que : ajouter l’email administrateur (étape du protocole 1.2.2) car elle est nécessaire pour l’accès administrateur aux outils et aux panneaux de tâches ; générer correctement la clé API pour l’extension de la plateforme du métavers (étape du protocole 1.5.3) et coller correctement dans le fichier de valeurs par défaut ; Et lors de l’ajout d’outi...

Matériaux

Liste des matériaux utilisés dans cet article

Nom	Entreprise	Numéro de catalogue	Commentaires
Bioblend	Galaxy Project	v1.2+	Bibliothèque Python fournissant un wrapper de haut niveau autour de l'API REST Galaxy. Cela est utilisé dans les scripts d'aide pour l'extension Omniverse pour lister les flux de travail, récupérer les définitions d'entrée et lancer des tâches. Installé automatiquement dans les images Docker pertinentes ; aucune installation sur l'hôte n'est requise.
Docker Containers	Docker	v24.0.5	Runtime de conteneurisation utilisé pour emballer chaque outil de simulation et de post-traitement avec toutes ses dépendances, assurant la portabilité et la reproductibilité.
Galaxy	Galaxy Project	v22.05	Moteur de workflow open-source utilisé pour orchestrer les outils de simulation et de traitement enchaînés et pour les exposer via une API REST.
Git	Git SCM	v2+	Requis pour cloner le dépôt afin de suivre le protocole
NVIDIA RTX GPU	NVIDIA	-	Requis pour le rendu en temps réel par rayons dans Omniverse (Section 3). Les utilisateurs sans matériel RTX peuvent compléter toutes les étapes jusqu'à la Section 2 et utiliser ParaView pour la visualisation (voir Discussion).
Omniverse	NVIDIA	Code 2022.3.3	Plateforme 3D collaborative de NVIDIA. Elle est utilisée comme interface de visualisation et d'interaction pour les résultats des workflows via une extension Kit personnalisée.
ParaView	Kitware	v5.11	Application de visualisation scientifique open-source utilisée comme solution de secours non-RTX pour inspecter les sorties intermédiaires.vtk/.vtp.
Protocol Repository	Custom	v1.0	Contient la configuration Galaxy ainsi que tous les wrappers XML des outils, les scripts d'exécution, les Dockerfiles, les données de test et l'extension Omniverse. Cloné à l'étape 1.2.1. Les fichiers clés sont également fournis en téléchargements supplémentaires directs (voir I.2).
Python	Python	v3.10+	Runtime requis pour le script d'exécution OpenMC et les scripts d'aide pour l'extension Omniverse. Inclus dans les images Docker pertinentes ou avec le téléchargement d'Omniverse ; aucune installation hôte séparée n'est requise.
The OpenMC Monte Carlo Code	OpenMC	v0.13.3	Code open-source de transport de particules Monte Carlo utilisé ici pour la simulation de nucléonique de fusion. Il fournit le rapport de production de tritium (TBR) et les sorties de trajectoire des neutrons.
Windows Subsystem for Linux (WSL)	Microsoft	v2	Requis pour exécuter Docker sur les hôtes Windows (installation via `wsl --install` dans PowerShell). Les utilisateurs Linux et Mac n'ont pas besoin de cela.