Integration automatisierter Simulations-Workflows mit 3D-Visualisierung für virtuelle Experimente im Metaverse

Zusammenfassung

Eine verallgemeinerte, FAIR-konforme Methode wird für Fachexperten vorgestellt, die Simulations- und Datenverarbeitungswerkzeuge in automatisierte Arbeitsabläufe für 3D-virtuelle Experimente integrieren möchten. Ein Beispiel für Neutronics zeigt, wie man eine lokale Galaxy-Instanz einrichtet, OpenMC und Dateikonvertierungstools umpackt, Workflows aus Omniverse startet und die konvertierten 3D-Ausgaben visualisiert.

Zusammenfassung

In vielen virtuellen Experimenten werden mehrere Softwarepakete mit unterschiedlichen Simulationstypen, Vor- und Nachbearbeitungswerkzeugen sowie Werkzeugen zur Visualisierung der Experimentergebnisse verwendet – oft eine Kombination aus allem. Die typische Methode zur Integration ist eine manuelle, mit maßgeschneiderten Lösungen für jeden Anwendungsbereich, die schlecht skalieren und das Teilen sowie die Reproduzierbarkeit erschweren.

Dieses Protokoll demonstriert die Bereitstellung und Nutzung eines lokal containerisierten Workflow-Systems. Anschließend starten Nutzer eine lokale Galaxy-Instanz mit Docker, erstellen und führen einen OpenMC-Neutronics-Simulations-Workflow aus, führen die Ausgaben durch eine Kette von Format-Konvertierungstools und laden die Ergebnisse sowohl in ParaView als auch in NVIDIA Omniverse zur Visualisierung. Die containerisierte Bereitstellung fördert Reproduzierbarkeit und Portabilität auf jeder Maschine, die die in Abschnitt 1 beschriebenen Hardwareanforderungen erfüllt.

Sobald das System läuft, können Workflows mit neuen Eingaben ohne manuelle Neukonfiguration erneut ausgeführt werden, zusätzliche Simulationscodes können mit geringem Aufwand als neue Werkzeuge eingewickelt werden, und Werkzeuge können in mehreren Arbeitsabläufen und Anwendungsbereichen eingesetzt werden. Der Ansatz unterstützt die Findable, Accessible, Interoperaable, Reuseable (FAIR)-Datenprinzipien: Laufzeiten erfassen vollständige Herkunftsmetadaten, Workflows sind als portable Dateien exportierbar und können direkt zwischen Galaxy-Instanzen geteilt werden, und Tools werden in versionskontrollierten Containern verpackt, die in einem öffentlichen Repository veröffentlicht werden können. Die Skalierbarkeit zu Hochleistungsrechnen (HPC) oder Cloud-Ressourcen über das Pulsar-System von Galaxy ist eine natürliche Erweiterung der hier beschriebenen Architektur.

Die Methode wird anhand einer Fallstudie zur Fusionsneutronik demonstriert. OpenMC wird verwendet, um Neutronentransport in einer Direct Accelerated Geometry Monte Carlo (DAGMC) computerunterstützten Designgeometrie (CAD) zu simulieren, wodurch ein Tritium-Brutverhältnis (TBR) und ein Neutronenspur-Datensatz erzeugt werden. Die Simulations-Workflows werden dann mit dem NVIDIA Omniverse als Metaverse-Plattform für Aufruf und Visualisierung verbunden.

Einleitung

Das industrielle Metaversum verbindet digitale und physische Welten, um Design, Simulation und kollaborative 3D-Visualisierung von entwickelten Systemen zu unterstützen. Sie besteht typischerweise aus vielen miteinander verbundenen digitalen Zwillingen von Komponenten, um eine Gesamtübersicht des Systems zu erhalten. Große Unternehmen wie Boeing, BMW, Amazon und viele mehr verfolgen verschiedene Ansätze, um Metaverse^zu schaffen. Es wurden Systeme entwickelt, die mehrere Ketten von Simulations- und Verarbeitungswerkzeugen ermöglichen, und werden eingesetzt. Diese Beispiele sind jedoch typischerweise entweder maßgeschneidert für den Anwendungsbereich² oder kommerzielle Optionen ^3,4 mit einer gewissen Bindung an proprietäre Systeme. Einige Open-Source-Alternativen zum Bau digitaler Zwillinge wurden verwendet, um einige Systeme zu erstellen, wie Python Flask mit integrierten Simulationsfunktionen. Dennoch sind diese als maßgeschneiderte Codestücke konfiguriert, um spezifische Aufgaben im Zusammenhang mit dem jeweiligen Modell⁵ auszuführen. Im Kontext dieses Protokolls fungiert die Metaverse-Plattform (NVIDIA Omniverse) als 3D-Visualisierungs- und Workflow-Interaktions-Frontend: Simulationsausgaben werden nach Abschluss eines Workflow-Laufs in eine gemeinsame Szene geladen, und neue Läufe können innerhalb derselben Umgebung ausgelöst werden. Dies unterscheidet sich von Live-Digital-Twin-Systemen, bei denen Echtzeit-Sensorfeeds das Modell kontinuierlich aktualisieren; Die hier demonstrierte Methode unterstützt die Ausführung von Batch-Workflows und die Nachbearbeitung der Ergebnisse. Dies geschieht jedoch so, dass zukünftige Arbeiten zur Integration weiterer Systeme in die Metaverse-Plattform unterstützt werden, um die Erstellung digitaler Zwillinge mit Workflow-Engines als rechnergestütztes Backend zu ermöglichen.

Workflows können als Ketten von Softwaretools definiert werden, die explizit den Datenfluss zwischen ihnen spezifizieren. Sie ermöglichen das Umpacken bestehender Simulationscodes, Verarbeitungsskripte und anderer Schritte in einer typischen Analysepipeline, ohne deren Funktion zu verändern, sondern stattdessen mit standardisierten, werkzeugunabhängigen Eingaben und Ausgaben zu konfigurieren und neu zu konfigurieren. Workflows ermöglichen eine einfache Replikation von Ergebnissen durch das Teilen von Werkzeugen und liefern außerdem Metadaten und Herkunft darüber, welche Versionen der Werkzeuge verwendet wurden, in welcher Reihenfolge und mit welchen Eingaben. Die Werkzeuge selbst können in vielen Simulationspipelines wiederverwendet werden, sodass Forscher weniger Zeit mit dem Aufbau von Simulationen und mehr Zeit mit der Planung von Experimenten und der Erforschung der Ergebnisse verbringen können. Workflow-Systeme sind ebenfalls skalierbar, mit Methoden, um sich mit verschiedenen lokalen Rechen-, Cloud- und HPC-Ressourcen zu verbinden, was es ermöglicht, viele groß angelegte Workflows auf spezifischer Hardware automatisiert auszuführen^.

Der typische manuelle Ansatz ist von Natur aus langsam, fehleranfällig und schwer nachzubilden, wobei ein Forscher jedes Simulations- oder Nachbearbeitungswerkzeug manuell ausführt, Zwischendateien zwischen Umgebungen verschoben und einzelne Eingaben und Ausgaben dokumentieren muss. Im Gegensatz dazu formalisiert ein Workflow-Manager den Datenfluss einmal und führt ihn deterministisch erneut aus. Dies bringt viele Vorteile im Vergleich zu manuellen Pipelines mit sich: Derselbe Workflow kann identisch auf verschiedenen Eingaben ausgeführt werden, was Parameterstudien ohne maßgeschneiderte Skripte unterstützt; Jeder Durchlauf erfasst automatisch vollständige Herkunftsmetadaten und schließt so jede Reproduzierbarkeitslücke; und sobald ein Tool gewrappt wurde, sinken die Wiederverwendungskosten in nachfolgenden Workflows auf nahezu null, abgesehen von der Rechenzeit. Diese Vorteile wurden für Bioinformatik von Wratten et ^al.7 und für Proteomik/Metabolomik von Perez-Riverol und Moreno⁸ sowie Verhoeven et ^al.9 quantifiziert.

Historisch gesehen wurden Workflows hauptsächlich im Bereich Bioinformatik ^8,9 mit großem Erfolg bei großen öffentlichen Instanzen wie dem europäischen ^{Galaxy-Server 10,11} eingesetzt, der bis 2022 mehr als 50.000 Nutzer, 2.500 Tools hostete, über 47 Millionen Jobs und 260.000 Workflow-Läufe ausführte. Der gleiche Workflow-Engine-Stack unterstützt die Skalierung auf HPC- und Cloud-Ressourcen über das Pulsar-verteilte Job-Execution-System ^6,11, mit operativen Deployments über 13 Pulsar-Endpunkte in 10 europäischen Ländern. Unter den vielen verfügbaren Workflow-Managern, darunter Snakemake, Nextflow, Toil und CWL-kompatible Engines, wurde die Galaxy Workflow^{Engine 11} aus mehreren Gründen ausgewählt. Einer der Hauptgründe ist die ausgereifte browserbasierte Benutzeroberfläche, die die Einstiegshürde für Fachexperten senkt, die nicht hauptsächlich über die Kommandozeile arbeiten; es stellt eine vollständige repräsentationsbasierte Zustandsübertragungs-(REST)-Anwendungsprogrammierschnittstelle (API) bereit (die im vorliegenden Werk zur Brücke zum Metaverse-Frontend verwendet wird); Seine Geschichte und das Arbeitsmodell erfassen die Herkunft in einer Form, die nicht spezialisierten Mitarbeitern leicht zugänglich ist; und es unterstützt eine transparente HPC-Entladung über das bereits erwähnte Pulsar-System (obwohl dies im Protokollabschnitt dieses Artikels nicht behandelt wird). Der in diesem Artikel beschriebene Ansatz ist jedoch prinzipiell workflow-engine-agnostisch: Äquivalente Integrationen könnten auf alternativen Engines aufgebaut werden. Der Beitrag dieser Arbeit ist nicht der Workflow-Manager selbst, sondern die Übertragung eines universellen Workflow-Managers, der ursprünglich für Bioinformatik entwickelt wurde, in andere Bereiche (mit dem konkreten Beispiel der Fusionsneutronik) und dessen Integration mit einer industriellen Metaverse-Plattform (NVIDIA Omniverse), innerhalb eines vollständig containerisierten, lokal einsetzbaren Stacks, der auf 3D-virtuelle Experimente angewendet wird.

Schließlich ermöglicht die Containerisierung das Teilen vieler Software, indem Code mit dem Betriebssystem und allen benötigten Abhängigkeiten mit dem Betriebssystem gepackt wird. Diese Umgebungen vermeiden das Problem fehlender Abhängigkeiten und den Aufwand bei der Installation einiger Simulationscodes. Sie sind funktional ähnlich wie virtuelle Maschinen, sind aber viel leichter und tragbarer. Sie erhöhen die Teilbarkeit und Reproduzierbarkeit von Softwarepaketen drastisch. Bei dieser Methode laufen der Workflow-Manager und die einzelnen Tools in^{Docker-12-Containern} , was die Kompatibilität mit verschiedenen Betriebssystemen erhöht, solange der Benutzer Container ausführen kann.

Dieses Protokoll richtet sich an Fachexperten, zum Beispiel Fusionsneutronik-Ingenieure, Analysten der rechnergestützten Strömungsdynamik oder Finite-Elemente-Praktiker, die mit den Simulationswerkzeugen ihres Fachgebiets vertraut sind, aber zuvor keinen Workflow-Manager oder containerbasierte Bereitstellung verwendet haben. Vertrautheit mit einem einzelnen Simulationscode und der grundlegenden Kommandozeilenfunktion wird vorausgesetzt; Vertrautheit mit Galaxy oder dem Omniversum nicht. Leser, die neu in der Containerisierung sind, sollten die offizielle Docker-Dokumentation (https://docs.docker.com/) oder die Einführungsschulungen konsultieren, die verfügbar sind unter: https://uomresearchit.github.io/docker-introduction/ vor dem Befolgen von Abschnitt 1; Die grundlegenden Befehle, die zum Ausführen der Software benötigt werden, sind alle im Protokoll enthalten.

Der Rest dieses Berichts behandelt die Einrichtung und Nutzung des lokal einsetzbaren Systems. Anschließend folgen Schritte zur Entwicklung neuer Tools für das System und einer Methode, um andere externe Pakete mit der Workflow-Engine zu verknüpfen, wie zum Beispiel einer Metaverse-Plattform. Im gesamten Bericht dient eine Neutronik-Simulation mit OpenMC¹³ als Fallstudie. OpenMC wurde ausgewählt, weil es die vollständige CAD-zu-Simulation-zu-Ausgabe-Visualisierungspipeline demonstriert, die die Workflow-Architektur motiviert. Eine Geometriedatei und eine Konfigurationsdatei dienen als strukturierte Eingaben; die Monte-Carlo-Neutronentransportsimulation erzeugt eine skalare Metrik (das Tritium-Brutverhältnis, TBR), die mit einem bekannten Wertebereich verglichen werden kann, sowie einen räumlich aufgelösten Neutronenspur-Datensatz, der verarbeitet und in einem visualisierbaren Format für die 3D-Darstellung in der Metaversum-Anwendung präsentiert werden kann.

Protokoll

HINWEIS: Ein Überblick über die lokale Workflow-Engine-Einrichtung, den Workflow-Aufbau, den Workflow-Start und die Visualisierungsausgaben ist in Abbildung 1, Abbildung 2, Abbildung 3, Abbildung 4, Abbildung 5, Abbildung 6, Abbildung 7 und Abbildung 8 dargestellt. Die Repository-Dateien, die zum Ausführen des Protokolls erforderlich sind, werden in Supplemental File 1 bereitgestellt.

1. Aufbau

1. Anforderungen
   HINWEIS: Diese Methode wurde auf der neuesten Long Term Support (LTS)-Version von Ubuntu, 22.04.1 LTS, getestet. Andere Versionen von Ubuntu und anderen Distributionen könnten funktionieren, aber sie wurden hier noch nicht getestet. Es funktioniert auch auf Windows-Systemen und nutzt Windows Subsystem for Linux (WSL) als Docker-Backend.
   1. Windows-Benutzer: Laden Sie WSL herunter und richten Sie es ein, da es für Docker eine Voraussetzung ist.
   2. Lade Docker herunter und verifiziere dann, indem du Folgendes ausführst:
      `Docker betreibt Hello-World'
      Das sollte eine Willkommensnachricht anzeigen.
   3. Lade den NVIDIA Omniverse-Launcher und eine der Omniverse-Apps über den Launcher herunter.
      HINWEIS: Das Echtzeit-Raytraced-Rendering von NVIDIA Omniverse erfordert eine RTX-Klasse GPU. Benutzer ohne diese Hardware können weiterhin den vollständigen Workflow über Abschnitt 2 ausführen und die zwischenliegenden .vtk - / .vtp-Ausgaben in ParaView inspizieren (siehe Diskussion). Diese Nutzer können Abschnitt 3 überspringen, da dies nur die Metaverse-Plattform betrifft; Die hier verwendeten Methoden zur Integration der Workflow-Engine können nützlich sein, wenn sie mit anderen Metaverse-Plattformen verbunden sind.
      Dieses Protokoll verwendet die App Omniverse Code, aber die anderen Omniverse-Apps sollten im Großen und Ganzen ähnlich sein. Obwohl nicht essentiell, kann ParaView verwendet werden, um einige der Zwischendateien, die von den Tools dieses Protokolls erzeugt werden, zu visualisieren.
2. Repository
   1. Klone das Repository, das alle Dateien und Skripte enthält, die für die lokale Workflow-Engine benötigt werden, sowie die in diesem Artikel beschriebenen Werkzeuge mit:
      'Git Clone https://github.com/williamjsmith15/galaxy-omniverse-example.git'
   2. Füge eine Admin-E-Mail zur Liste der Admin-Nutzer hinzu.
      HINWEIS: Dies gewährt Administratorrechte, die für einige Funktionen der Workflow-Engine erforderlich sind, und sind unter dem Abschnitt admin_users in der galaxy-config/galaxy.yml-Datei zu finden (siehe https://github.com/williamjsmith15/galaxy-omniverse-example/blob/master/galaxy-config/galaxy.yml).
   3. Benenne die Datei default.json.template in default.json. Diese Datei befindet sich unter omni_exts/omni.galaxy.example/omni/galaxy/example/default.json.template.
      HINWEIS: Dadurch kann die Erweiterung der Metaverse-Plattform gelesen werden und persönliche Einstellungen zwischen den Ladevorgängen hinzugefügt und beibehalten werden – weitere Änderungen werden nach der Einrichtung der Galaxy-Instanz vorgenommen.
3. Lokale Workflow-Engine-Server starten
   1. Starten Sie die Workflow-Engine-Instanz, indem Sie die start-galaxy.sh-Datei in der obersten Ebene des Repositorys ausführen:
      './start-galaxy.sh'
      Wenn die Datei hier nicht ausgeführt wird, muss sie möglicherweise ausführbar gemacht werden, falls sich die Berechtigungen im Repository-Klon geändert haben. Dies kann durch Ausführen erfolgen:
      'chmod a+x start-galaxy.sh'
      HINWEIS: Windows-Nutzer müssen dies über ihr WSL-Terminal tun. Dadurch werden die relevanten Dateien heruntergeladen und die Workflow-Engine-Instanz gestartet, die in jedem Browser, der auf demselben Rechner läuft, auf http://localhost:8080 angezeigt werden kann. Dies sollte die in Abbildung 1 gezeigte Seite anzeigen; Wenn nicht, warten Sie und aktualisieren Sie – die Workflow-Engine-Instanz kann einige Zeit brauchen, um zu starten (besonders beim ersten Mal).
      1. Um die Änderungen im Repository in der Workflow-Engine Instanz zu sehen, führen Sie im Allgemeinen './restart-galaxy.sh' oder './stop-galaxy.sh' aus und starten Sie das Skript dann von vorne.
4. Metaverse-Plattformkonfiguration
   1. Öffne die App, nachdem du den Launcher und die App heruntergeladen hast (für dieses Beispiel Omniverse Code).
   2. Oben links im Fenster klicken Sie auf den Reiter Erweiterungen (in anderen Apps befindet sich dies unter Fenster | Erweiterungen).
   3. Im Erweiterungsfenster klickt man auf die graue Einstellungstaste ; Es öffnet ein Fenster mit einigen bereits gefüllten Verzeichnissen. Füge einen weiteren Pfad hinzu, der auf den omni_exts-Ordner verweist, indem du auf die grüne Plus-Schaltfläche klickst, und füge einen Pfad hinzu, der das Format hat: '/galaxy-omniverse-example/omni_exts'; siehe Abbildung 2 für weitere Details.
   4. Suche nach einem neuen Eintrag namens 'OMNI GALAXY EXAMPLE' in der linken Spalte unter dem Tab THIRD PARTY . Schalte den Schieberegler dieser Erweiterung auf ein und warte, bis das Erweiterungsfenster erscheint.
   5. Wähle das Kontrollkästchen für Autoload, um die Erweiterung automatisch zu laden, jedes Mal, wenn die App gestartet wird.
      HINWEIS: Änderungen an den Erweiterungsdateien sollten automatisch beibehalten werden, wenn die Datei gespeichert wird, da Omniverse ein Hot-Read-Loading von Erweiterungen erlaubt
5. Erstellung von Workflow-Engine-Accounts und Verbindung zum Metaverse
   1. In der Workflow-Engine-Instanz erstellen Sie ein Konto, indem Sie auf die Schaltfläche Anmelden oder Registrieren in der oberen Leiste klicken, dann Hier registrieren und anschließend die Details mit der in Schritt 1.2.2 hinzugefügten E-Mail-Adresse eingeben, um ein Konto mit Administratorzugriff zu erstellen.
   2. Generiere einen API-Schlüssel, damit die API mit der Workflow-Engine kommunizieren kann. Gehe in der oberen Leiste zum Benutzer-Dropdown-Menü | Präferenzen | API-Schlüssel verwalten. Erstellen Sie einen Schlüssel und kopieren Sie ihn.
   3. Sobald der Schlüssel generiert wurde, fügen Sie ihn der in Schritt 1.2.3 erstellten default.json-Datei unter dem Feld 'galaxy_api_key' in den leeren Anführungszeichen hinzu.
      VORSICHT: Diese Datei enthält nun einen API-Schlüssel. Dieser API-Schlüssel kann verwendet werden, um Jobs auszuführen und auf Daten des zugehörigen Kontos zuzugreifen. Es sollte kein Problem in einer lokalen Bereitstellung sein, in der keine öffentlich zugängliche Domain oder IP-Adresse vorhanden ist; Diese Datei sollte weiterhin als geheim behandelt werden und daher nicht geteilt oder in ein öffentliches Repository eingetragen werden (die Datei ist standardmäßig in .gitignore aufgeführt, um dem entgegenzuwirken).
   4. Starte die Metaverse-Plattform-App neu, um die Änderungen in der Standarddatei zu aktualisieren.
      HINWEIS: Der API-Schlüssel kann auch direkt im Erweiterungsfenster im Dropdown-Menü für Servereinstellungen hinzugefügt werden, allerdings bleibt dieser zwischen den Sitzungen nicht bestehen.

2. Ausführung von Jobs auf der Workflow-Engine

1. Einzelwerkzeuge
   HINWEIS: Einzelne Werkzeuge ermöglichen es, einzelne Verarbeitungs- oder Simulationsschritte isoliert auszuführen und zu überprüfen, was nützlich ist, um sicherzustellen, dass Eingaben korrekt formatiert sind und ein Werkzeug wie erwartet funktioniert, bevor es in einen Workflow integriert wird. Die unten referenzierten Testdateien, dagmc.h5m (die CAD-Geometrie von DAGMC) und openmc_config.json (die Simulationskonfiguration), befinden sich im test_files-Verzeichnis des geklonten Repositorys.
   1. Laden Sie die erforderlichen Eingabedateien hoch, indem Sie in der linken Spalte auf Daten hochladen klicken und entweder lokale Dateien auswählen oder vom Dateiexplorer in dieses Fenster ziehen und abladen. Lade die dagmc.h5m (CAD-Datei) und openmc_config.json (Konfigurationsdatei) hoch und klicke dann auf die Start-Taste , um den aktuellen Verlauf hochzuladen. Beide Dateien erscheinen nach Abschluss des Hochladens grün im History-Panel rechts.
   2. Wählen Sie das Dropdown-Menü Komplexe Werkzeuge in der linken Spalte der Landingpage und dann das OpenMC Neutronics Simulations-Werkzeug .
   3. Wähle auf der toolspezifischen Seite die Eingaben aus den Dateien aus, die in Step 2.1.1 hochgeladen wurden, und wähle die CAD-Datei als dagmc.h5m-Datensatz und die Konfigurationsdatei als openmc_config.json-Datensatz .
   4. Klicken Sie auf die Schaltfläche "Ausführen ". Zwei neue Dateien (TBR und Tracks) erscheinen im History-Panel rechts auf dem Bildschirm. Sie werden beim Laufen orange und grün, wenn sie abgeschlossen und erfolgreich sind, Rot würde auf einen Werkzeugausfall hinweisen. Siehe Abschnitt 4 für Debugging-Schritte.
   5. Der TBR-Wert (Tritium-Brutverhältnis) kann visualisiert werden, um sicherzustellen, dass der Testfall erfolgreich durchgeführt wurde. Klicken Sie auf die TBR-Ausgabe zum Erweitern, dann auf das Diagrammsymbol und schließlich auf den Editor. Dadurch wird das TBR-Ergebnis angezeigt, das etwa 0,76 betragen sollte (dies ist eine statistische Methode, und die Konfiguration hier verwendet eine kleine Stichprobengröße für die Simulationsgeschwindigkeit, daher variieren die Ergebnisse).
      HINWEIS: Der TBR-Wert ist stochastisch; Der Wert von 0,76 kann um ±0,01 variieren und dies spiegelt eine bewusst geringe Partikelanzahl wider (5 Chargen zu je 1.000 Partikeln), die für schnelle Beispiel-Workflows ausgewählt wurden. Um den Wertbereich zu reduzieren, erhöhen Sie die Anzahl der Chargen und Partikel unter dem Einstellungsfeld in der openmc_config.json-Datei, bevor Sie erneut ausgeführt werden. Als Richtlinie für eine einfache Geometrie wie den hier dargestellten Fall sollten 50 Chargen mit 10.000 Partikeln die Streuung von TBR-Werten in nachfolgenden Durchläufen reduzieren, allerdings auf Kosten einer längeren Laufzeit.
   6. Andere Werkzeuge können auf der Tracks-Ausgabe des Workflows ausgeführt werden, um die Ergebnisse nachzubearbeiten. Führe das Tracks h5-zu-vtp-Tool auf der Tracks-Ausgabe aus und dann das CAD-h5m-zu-vtk-Tool auf der dagmc.h5m-Eingabedatei . Beide erzeugen eine Ausgabe, tracks_0.vtp und dagmc.vtk, die sie in ein besser visualisierbares Format umwandeln.
   7. Die im vorherigen Schritt erzeugten Ausgaben können aus der Instanz heruntergeladen werden (indem man auf die Ausgabe und dann auf das Speichersymbol klickt) und können dann in ParaView¹⁴ visualisiert werden, um die simulierten Neutronenspuren zu sehen.
   8. Um die Ergebnisse in ParaView zu visualisieren, importiere die heruntergeladenen tracks_0.vtp - und dagmc.vtk-Ausgaben . Diese erscheinen auf der linken Seite des Fensters. Klicken Sie entweder auf das Auge-Symbol neben den importierten Dateien oder auf die Schaltfläche "Anwenden " unten im Eigenschaftenfenster, um die Ausgabe zu visualisieren. Dies sollte ähnlich sein wie in Abbildung 7.
2. Arbeitsabläufe
   HINWEIS: Ein Workflow kodiert eine vollständige Verarbeitungspipeline als gerichtetes Diagramm von Werkzeugen mit deklarierten Eingaben und Ausgaben. Nach der Definition kann derselbe Workflow mit jeder beliebigen Eingabedatei erneut ausgeführt werden, ohne jedes Tool manuell neu konfigurieren zu müssen, und alle Laufzeit- und Herkunftsmetadaten werden automatisch erfasst.
   1. Klicken Sie oben in der Navigationsleiste auf Workflow und oben rechts auf Erstellen . Geben Sie einen Namen und eine Beschreibung für den Workflow ein (alles ist in Ordnung), und klicken Sie dann erneut auf Erstellen .
   2. Füge drei Werkzeuge zum Workflow hinzu, öffne die entsprechenden Abschnitte im Werkzeugmenü und füge die Werkzeuge hinzu, die in Abschnitt 2.1 verwendet werden: OpenMC Neutronics Simulation, CAD h5m zu vtk und Tracks h5 zu vtp.
   3. Definiere den Datenfluss zwischen den Werkzeugen. Ziehe die Werkzeuge durch den Arbeitsbereich, indem du auf die dunkelblaue obere Leiste jedes einzelnen klickst und ziehst. Verbinden Sie die Tracks-(h5)- Ausgabe des Neutronik-Simulationstools mit der tracks.h5-Eingabe des h5-zu-VTP-Tools. Mach das, indem du klickst und ziehst vom Pfeil am Ausgang zum Pfeil auf der Eingabe.
   4. Definieren Sie die Eingabedatensätze auf Workflow-Ebene. Im Bereich Eingaben der Werkzeuge klicken Sie zweimal auf Eingabedatensatz, um zwei Eingabeknoten zu erstellen. Benenne eine für die Konfigurationsdatei und die andere für die CAD-Eingabe um, indem du auf den Schritt klickst und dann das Label-Feld im rechten Eigenschaftenmenü änderst.
   5. Verknüpfen Sie die Konfigurationsdatei und die CAD-Datei mit den Eingaben des Neutronik-Simulationswerkzeugs und die CAD-Datei mit dem h5m-zu-vtk-Werkzeug, entsprechend dem Muster in Abbildung 3.
   6. Speichere den Workflow mit dem Speichersymbol oben rechts.
   7. Um den Workflow auszuführen, klicken Sie wie zuvor auf den Workflow-Tab in der oberen Leiste und klicken Sie dann auf das Play-Symbol im zu startenden Workflow. Dann wähle die Eingaben wie bei Schritt 2.1.2 aus, genauso wie beim Ausführen eines Tools, und klicke auf Workflow ausführen.
   8. Warte, bis der Workflow ausgeführt ist, und dann können die Ausgaben mit den Schritten 2.1.5 und 2.1.8 verglichen werden; Diese sollten sehr ähnlich sein (beachten Sie erneut die statistische Variation dieser Schritte). Der Workflow ist erfolgreich ausgegangen, wenn alle Ausgaben in der Historie grün geworden sind. Hier sollten (neben den Eingabedatensätzen) vier Datensätze vorhanden sein: TBR, Tracks, dagmc.vtk und tracks_0.vtp.
   9. Während der Workflow ausgeführt wurde, möchten einige Nutzer möglicherweise die Herkunft und Metadaten des Workflow-Aufrufs (Ausführens) sehen können. Dies kann erreicht werden, indem man auf Benutzer in der oberen Leiste | Workflow-Aufrufe navigiert. Dies führt zu einer Liste aller vom Benutzer durchgeführten Workflows, klickt auf den Pfeil nach unten im interessierten Workflow und kann dann die Metadaten-JSON-Datei herunterladen, indem man auf die Schaltfläche "BioCompute Object herunterladen " klickt. Dies enthält Herkunft über die verwendeten Werkzeuge/Workflows, verwendete Eingaben usw.
      HINWEIS: Die Workflow-Engine zeichnet außerdem eine vollständige Laufzeithistorie für jede Workflow-Ausführung auf, einschließlich Prüfsummen für Eingabedateien, Werkzeugversionen und Parameterwerte. Um den Herkunftseintrag für einen Durchlauf herunterzuladen, öffnen Sie das Historie-Panel , klicken Sie oben rechts auf das Menü (Pfeil nach unten) und wählen Sie "Geschichte in Datei exportieren". Das exportierte Archiv enthält alle Datensätze und eine maschinenlesbare Aufzeichnung der Schritte, die sie erzeugt haben.
      Das Speichern von Herkunft oder Historien, die von der Workflow-Engine generiert werden, kann über die in Abschnitt 5.1 beschriebene API automatisiert werden; dies wird jedoch in diesem Protokoll nicht näher ausgeführt werden.
3. Komplexeren Arbeitsablauf
   HINWEIS: Dieser Workflow erweitert Abschnitt 2.2, indem er Nachbearbeitungsschritte hinzufügt, die Universal Scene Description (USD)-Dateien erzeugen, die für die Visualisierung in der Metaverse-Plattform benötigt werden. Da kein einzelnes Werkzeug direkt von DAGMC (.h5m) oder VTK (vtp) in USD konvertiert, leitet die Pipeline Daten durch zwei mehrstufige Umwandlungsketten: Die CAD-Geometrie folgt einer H5M-, STL-, OBJ- UND USD-Pipeline, und die Neutronenspuren folgen H5, VTP, OBJ, USD.
   1. Befolgen Sie die Schritte zur Einrichtung eines Workflows, wie in Abschnitt 2.2 gezeigt, und folgen dem in Abbildung 4 gezeigten Workflow.
   2. Definiere die beiden Workflow-Level-Eingaben wie in Schritt 2.2.4 und nenne sie CAD DAGMC und Konfigurationsdatei.
   3. Füge das OpenMC Neutronics Simulation Tool hinzu und verbinde die CAD-, DAGMC - und Konfigurationsdatei-Eingänge wie in Schritt 2.2.3 mit den entsprechenden Eingängen.
   4. Erstellen Sie die Neutronik-Umwandlungskette. Füge die Spuren h5 zu vtp, vtp zu obj und obj zu USD-Werkzeugen hinzu und verbinde dann die Ausgänge jedes Stücks mit den Eingängen des nächsten, entsprechend dem Layout im unteren Zweig von Abbildung 4.
   5. Erstellen Sie die CAD-Umwandlungskette. Füge das h5m zu STL, STL zu OBJ und OBJ zu USD-Tools hinzu und verbinde dann erneut die Ausgänge jedes Instruments mit den Eingängen des nächsten, entsprechend dem Layout im oberen Zweig von Abbildung 4.
   6. Speichere den Workflow, der jetzt bereit für die Nutzung in der Metaverse-Plattform über die Erweiterung in Abschnitt 3 ist.
      HINWEIS: Diese zusätzlichen Schritte zeigen den Nutzern, wie Workflows und Werkzeuge geteilt werden können, was Reproduzierbarkeit und Zugänglichkeit zu den Daten und Methoden zur Ergebniserzeugung ermöglicht.
   7. Exportiere den Workflow als portable Datei, indem du in der oberen Leiste zum Workflow navigierst, auf das Menü (Pfeil nach unten) klickst und Herunterladen auswählst. Der Workflow-Manager speichert eine .ga-JSON-Datei , die dann von jedem mit denselben Tools in seiner Workflow-Engine-Instanz geteilt und genutzt werden kann. Dies kann über Workflow in der oberen Leiste | Import importiert werden.
   8. Teilen Sie Tools, indem Sie den galaxy-tools/ Ordner des geklonten Repositorys auf einen öffentlichen Versionskontroll-Host einmitten. Bitten Sie die Kollaborateure, dies zu klonen, um Zugriff auf alle containerisierten Tools zu erhalten und sie auf die gleiche Weise wie auf dem lokalen Gerät des Verlags auszuführen.
      HINWEIS: Öffentliche Workflow-Manager-Instanzen können konfiguriert werden, was das manuelle Teilen von Workflow- und Tooldateien zwischen lokalen Deployments umgeht. In diesen Fällen sind Werkzeuge für alle Nutzer zugänglich, und Arbeitsabläufe sowie Verläufe können allen anderen Nutzern zugänglich gemacht werden. Dies liegt außerhalb des Anwendungsbereichs dieses Protokolls, aber weitere Informationen finden Sie im offiziellen Galaxy Training-Netzwerk zur dauerhaften Bereitstellung: https://training.galaxyproject.org/training-material/topics/admin/tutorials/ansible-galaxy/tutorial.html oder der im Repository angegebene Docker-Compose-Stack können auf einem Server unverändert und dann über einen Proxy oder ähnliche Weise weitergeleitet werden, um ihn öffentlich zugänglich zu machen.

3. Ausführung eines Workflows von der Metaverse-Plattform

1. Start des Workflows
   1. Im Fenster der Metaverse-Plattformerweiterung klicken Sie auf Workflows abrufen (Anmerkung 2, Abbildung 5). Ein Dropdown-Menü zeigt alle auf dem Workflow-Engine-Konto verfügbar, das mit dem in default.json gespeicherten API-Schlüssel verknüpft ist. Falls dies nicht der Fall ist, überprüfen Sie, ob der API-Schlüssel korrekt in der JSON-Datei gespeichert wurde, und starten Sie die Metaverse-Plattform-App neu, um sicherzustellen, dass der Schlüssel erkannt wird.
   2. Wählen Sie für die Liste den komplexen Workflow aus und klicken Sie dann auf Eingaben abrufen (Anmerkung 4, Abbildung 5). Die im Workflow definierten Eingabefelder (Schritt 2.3.2) erscheinen und sollten denselben Namen tragen.
   3. Für jede dateibasierte Eingabe klicken Sie auf Datei auswählen und verwenden Sie das Dateiexplorer-Popup, um die entsprechende lokale Datei auszuwählen: dagmc.h5m für die CAD-DAGMC-Eingabe und openmc_config.json für die Konfigurationsdatei-Eingabe .
   4. Klicken Sie auf Launch Workflow (Anmerkung 6, Abbildung 5). Eine Startbestätigungsmeldung wird im Info-Bereich angezeigt (Anmerkung 7). Nach Abschluss des Workflows bestätigen weitere Nachrichten, dass die Ausgabedateien gespeichert wurden und der Lauf abgeschlossen ist.
      HINWEIS: Der Fortschritt der Workflow-Jobs kann über die Weboberfläche der Workflow-Engine bei http://localhost:8080 überwacht werden, indem man zu Admin | Jobs navigiert. Administratorzugriff ist erforderlich (siehe Schritt 1.2.2).
2. Visualisierung der Ergebnisse
   HINWEIS: Nach Abschluss jeder Workflow-Ausführung lädt das System die Ausgabedateien automatisch von der Workflow-Engine in ein lokales Ausgabeverzeichnis herunter. Der Speicherpfad wird durch den output_dir-Schlüssel in der default.json-Datei der Erweiterung gesteuert. Jeder Durchlauf wird in einem zeitgestempelten Ordner gespeichert, sodass Ausgaben durch die Erweiterung unterschieden werden können. Wenn es Probleme bei der Visualisierung auf der Metaverse-Plattform gibt, können die Dateien in diesen Ordnern abgerufen und manuell angezeigt werden, um zu sehen, ob das Problem bei der Workflow-Engine liegt.
   1. Erweitern Sie in der Metaverse-Plattform den Bereich Dateimanager (Anmerkung 1, Abbildung 6) und klicken Sie auf Aktualisieren (Anmerkung 2). Dies ruft die Liste der abgeschlossenen Workflow-Läufe ab, die im lokalen Verzeichnis gespeichert sind.
   2. Im Verzeichnis-Dropdown-Menü (Annotation 3, Abbildung 6) wählen Sie den Ordner für den aktuellen Workflow-Lauf aus (bestätigen Sie, dass dies derzeit der einzige ist) und klicken Sie erneut auf Aktualisieren , um das Datei-Dropdown-Menü mit Ausgaben aus diesem Lauf zu füllen.
   3. Wählen Sie eine Datei aus dem Dropdown-Menü Dateien aus (Anmerkung 4, Abbildung 6; derzeit werden nur .usd-, .txt-, .json - und .out-Dateien unterstützt) und klicken Sie dann auf Datei ziehen (Anmerkung 5). Textbasierte Dateien werden im Info-Panel angezeigt, USD-Dateien werden der aktuellen Szene hinzugefügt und sollten im Hauptansichtsfenster visualisiert werden.
   4. Um die importierte Geometrie mit der Koordinatenkonvention von Omniverse auszurichten, öffnen Sie das Stage-Panel auf der rechten Seite, wählen beide importierten Workflow-Objekte aus und setzen Sie im Property-Panel direkt darunter Rotate X auf −90°. Dies korrigiert die Diskrepanz zwischen der z-up-Konvention, die von den USD-Exporttools verwendet wird, und der y-up-Konvention von Omniverse. Wenden Sie diese Rotation sowohl auf die CAD-USD- als auch auf die USD-Track-Datei an; der erwartete Ansichtszustand nach der Ausrichtung ist in Abbildung 8 dargestellt.
   5. Schließlich können Materialien zugewiesen werden, um mehr Kontrast zwischen den Teilen zu erzielen. Dies geschieht, indem man den Reiter Materialien am unteren Rand der App öffnet, ein Material auswählt und dann in der Stage-Ansicht in der rechten Spalte auf die Geometrie zieht und ablegt. Mach das bei beiden importierten Geometrien, um den Kontrast zwischen ihnen zu erhöhen.

4. Neue Werkzeuge hinzufügen

HINWEIS: Dieser Abschnitt beschreibt den Entwicklerprozess zur Erstellung und Bereitstellung neuer Workflow-Tools. Es erfordert Zugriff auf das Dateisystem des Repositorys und Administratorzugriff auf die Workflow-Engine zum Debugging. Nutzer, die nur bestehende Tools und Workflows ausführen oder Workflows erstellen müssen, müssen diesem Abschnitt nicht folgen.

1. Allgemeiner Ablauf
   1. Entwickle und teste das Simulations- oder Verarbeitungsskript unabhängig von der Workflow-Engine, bevor du es umpackst. Der Tools-Wrapper ruft ein bestehendes Arbeitsskript auf; die Implementierung neuer Logik während der Entwicklung eines Tools wird nicht empfohlen.
   2. Bereiten Sie die Ausführungsumgebung für das Skript vor, indem Sie ein Docker-Image erstellen, das alle Laufzeitabhängigkeiten (Bibliotheken, Binären, Datendateien usw.) enthält, die vom Skript benötigt werden.
      HINWEIS: Alle Beispielwerkzeuge in diesem Protokoll verwenden Docker-Container als Ausführungsumgebung. Conda-Umgebungen werden ebenfalls von der Workflow-Engine unterstützt, aber hier nicht demonstriert. Weitere Informationen zu Docker finden Sie in der offiziellen Dokumentation, oder einen guten Einführungskurs finden Sie hier: https://uomresearchit.github.io/docker-introduction/ .
   3. Erstellen Sie eine XML-Tool-Definitionsdatei, die die Ausführungsumgebung (in diesem Fall Docker), den Befehl zum Aufruf des Skripts sowie die Eingaben, Ausgaben und Metadaten der Werkzeuge zur Darstellung in der Schnittstelle der Workflow-Engine deklariert.
   4. Sobald der Wrapper erstellt wurde, legt man das XML und alle Skripte in einen neuen Ordner galaxy-tools// im Repository. Fügen Sie einen neuen Eintrag für das Tool in galaxy-tools/tool_conf.xml unter den entsprechenden Tags hinzu, der auf den entsprechenden Dateipfad der neu erstellten XML-Datei zeigt.
      HINWEIS: Stellen Sie sicher, dass dieser Dateiname exakt kopiert wird, da dies ein häufiger Fehler beim Versuch ist, neue Werkzeuge zu implementieren. Wenn der tool_conf.xml-Eintrag einen falschen Pfad enthält oder die XML-Datei einen Syntaxfehler aufweist, startet die Workflow-Engine-Instanz nicht. Um die Workflow-Container-Logs auf Fehlermeldungen zu überprüfen, führen Sie Folgendes vom Repository-Root aus:
      'Docker erstellt Logs Galaxy'
      XML-Parsefehler erscheinen als Zeilen des Formulars ERROR Loading Tool
   5. Deploye die Workflow-Engine neu, um das neue Tool zu laden, indem du das Restart-Skript aus dem Repository-Root ausführst: ./restart-galaxy.sh.
   6. Bestätigen Sie, dass das Werkzeug korrekt registriert wurde. Navigiere zu http://localhost:8080, finde das Werkzeug im Werkzeugfeld und klicke auf das Werkzeug, um sicherzustellen, dass alle Eingaben wie erwartet angezeigt werden. Wenn das Tool fehlt, befolgen Sie die obige Anmerkung zum Debugging, und falls weiterhin Fehler auftreten, überprüfen Sie die Syntax der Werkzeug-XML selbst, da dies ebenfalls zu Bereitstellungsfehlern führen kann.
   7. Führe das neue Tool wie zuvor aus, aber mit bereits getesteten Eingaben. Die Ausgänge sollten im History-Panel grün werden
   8. Wenn die Tools ausfallen, klicke als Administrator auf die fehlgeschlagene (rote) Ausgabe und klicke auf das Info-Symbol . Dies zeigt eine detaillierte Ausgabeseite und zeigt die Stdout- und Stderr-Streams an. Diese können erweitert werden, um weitere Informationen zum Debuggen des Tools zu erhalten.
2. Einfache Werkzeuge
   HINWEIS: Die Werkzeuge 1–5 veranschaulichen zunehmend komplexere Umwicklungsmuster. Die XML-Datei und alle Skripte für jedes Tool befinden sich im entsprechenden Unterverzeichnis galaxy-tools/simple// des Repositorys. Setzen Sie jedes Tool aus und führen Sie es gemäß den Schritten 4.1.4–4.1.5 und Abschnitt 2.1 aus.
   Werkzeug 1 – Ausführen eines einfachen Befehls
   1. Schau dir die Datei galaxy-tools/simple/1/1.xml an. Das Anforderungselement spezifiziert eine Linux-Ausführungsumgebung. Das Befehlselement enthält den Echo-Befehl zum Ausführen.
   2. Führe Tool 1 über die Workflow-Engine-Oberfläche aus, ohne dass Eingabedateien benötigt werden. Da auch keine Ausgabedateien definiert sind, gehe als Admin zur Seite Admin, Jobs und klicke dann auf das Informationssymbol , um die stdout- und stderr-Streams zu sehen, was wie in Schritt 4.1.8 entspricht. Der stdout-Stream sollte nur die 'hello world'-Zeichenkette aus dem Befehl in der XML-Datei enthalten.
      Werkzeug 2 – Verwendung textbasierter Eingabe
   3. Schau dir die galaxy-tools/simple/2/2.xml-Datei an. Es gibt jetzt einen Eintrag im Eingabefeld mit einem Param-Element von type="text", und der Befehlsbereich verweist nun auf die Eingabevariable anhand des Namens-Tags.
   4. Führe Tool 2 wie zuvor aus; Diesmal gib dem Werkzeug eine Eingabe eines Strings. Das kann alles sein, was der Nutzer wünscht. Schauen Sie sich die Ausgabe wie in Schritt 4.2.2 an, und die Stdout-Ausgabe sollte die Zeichenfolge sein, die der Benutzer in der Werkzeugeingabe angegeben hat.
      Werkzeug 3 – Verwendung einer dateibasierten Eingabe
   5. Schauen Sie sich erneut die Werkzeugdatei an; Anstelle eines String-Inputs verwendet der Eingabeparameter ein Type="Data"-Tag, das die Verwendung einer Datei ermöglicht. Dies wird im Befehlsabschnitt als Dateipfad referenziert, wiederum unter Verwendung des Eingabeparameters.
   6. Erstellen Sie eine .txt-Datei mit einem lokalen Texteditor, falls nicht ausführen:
      'Echo "Hallo Welt aus einer Datei" > test_files/input.txt'
      aus dem Root-Ordner des Repositorys, um die Beispieleingabe zu generieren.
   7. Lade die erstellte .txt Datei wie in Schritt 2.1.1 hoch und führe dann Tool 3 wie zuvor aus, wobei du die hochgeladene Datei .txt als Eingabe auswählst. Betrachten Sie den Stdout auf dieselbe Weise, und der Inhalt der .txt Datei sollte dort angezeigt werden. Wenn man den obigen Befehl verwendet, sollte die Ausgabe "Hallo-Welt aus einer Datei" sein.
      Werkzeug 4 – Ausgabe in eine Datei schreiben
   8. Schau dir galaxy-tools/simple/4/4.xml an. Ein Ausgabebereich deklariert nun eine benannte Ausgabedatei, auf die im Befehlsbereich referenziert werden kann.
   9. Führe das Tool wie zuvor mit der .txt Eingabe aus, aber jetzt kann der reguläre Benutzer nicht mehr als Admin angezeigt werden, sondern vom regulären Benutzer in diesem History-Panel sichtbar werden, und bei einem erfolgreichen Durchlauf wird es grün und kann wie in den vorherigen Abschnitten beschrieben heruntergeladen und in der Workflow-Engine angezeigt werden.
      Werkzeug 5 – Skripte in Tools ausführen
   10. Untersuchen Sie galaxy-tools/simple/5/5.xml und das dazugehörige Python-Skript galaxy-tools/simple/5/5.py. Im XML verweist der Befehl auf das Python-Skript aus dem Tool-Verzeichnis, und der Anforderungsabschnitt verweist nun auf ein Python-Image, da Python benötigt wird, um das Skript auszuführen.
   11. Deploye und führe das Tool auf die gleiche Weise aus, und es sollte sich genauso verhalten wie Tool 4 (Schritt 4.2.9), nur dass es diesmal ein Skript und nicht direkt den Befehl ausführt.
3. Beispiel für ein komplexes Werkzeug
   HINWEIS: Dieser Abschnitt dokumentiert die Entwicklung des Neutronikwerkzeugs als ausgearbeitetes Beispiel des in Abschnitt 4.1 beschriebenen Musters. Die relevanten Dateien sind in galaxy-tools/complex/openmc/. Das gleiche Muster verallgemeinert sich auf jeden Simulations- oder Verarbeitungscode.
   1. Entwickle das Run-Skript für die Simulation. In diesem Beispiel führt das Skript galaxy-tools/complex/openmc/openmc_run.py eine Konfigurationsdatei (openmc_config.json) aus, schreibt die Neutronics-Einstellungsdatei und führt die Simulation aus. Teste das Skript direkt aus der Kommandozeile, bevor du es in einem Docker-Image verpackst.
   2. Baue die Docker-Ausführungsumgebung mit der Dockerfile bei galaxy-tools/complex/openmc/Dockerfile. Das erweitert das öffentliche Image mit ein paar zusätzlichen Paketen. Baue und tagge lokal oder referenziere es aus einer Container-Registry.
   3. Erstellen Sie den XML-Wrapper galaxy-tools/complex/openmc/openmc.xml und deklarieren Sie das Docker-Image aus Schritt 4.3.2 im Anforderungsabschnitt . Der Befehl, der zusammen mit den Eingabe- und Ausgabedateien ausgeführt wird (wie im Beispiel in Abschnitt 4.2), sollte ebenfalls definiert werden.
   4. Setzen Sie das Tool wie in den Schritten 4.1.4-4.1.7 ein und verwenden Sie dann die Testeingaben aus Abschnitt 2, um sicherzustellen, dass das Tool korrekt funktioniert.
      HINWEIS: Die übrigen Werkzeuge in der Instanz (Tracks h5 zu vtp, CAD h5m zu vtk, h5m zu stl, stl zu obj, vtp zu obj, obj zu USD) sind Dateiformat-Konverter nach demselben Entwicklungsmuster. Ihre XML-Dateien befinden sich im Verzeichnis galaxy-tools/complex/ und können als weitere Referenzbeispiele dienen.

5. Workflows mit dem Metaverse verbinden

HINWEIS: Dieser Abschnitt bietet Entwicklerreferenzmaterial, das die API-Integration der Workflow-Engine und die Architektur der Metaverse-Plattformerweiterung beschreibt. Nutzer, die nur Workflows von der Metaverse-Plattform ausführen müssen, sollten Abschnitt 3 befolgen und müssen diesen Abschnitt nicht lesen. Entwickler, die eine andere Frontend-Anwendung mit der Workflow-Engine verbinden möchten, sollten mit Abschnitt 5.1 beginnen.

1. Workflow-Engine-API
   HINWEIS: Galaxy stellt eine RESTful-API zur Verfügung. Die Bioblend Python-Bibliothek bietet einen höherstufigen Wrapper um diese API und bildet die Grundlage für alle in diesem Protokoll verwendeten Helferskripte. Bioblend wird automatisch in den relevanten Docker-Ausführungsumgebungen installiert, die im Repository bereitgestellt werden.
   1. Importiere Bioblend und stelle eine Verbindung zur laufenden Workflow-Engine her, indem du ein GalaxyInstance-Objekt mit Serveradresse und API-Schlüssel aus Schritt 1.5.2 instanziierst. In Python in einer Umgebung mit installiertem Bioblend:
      `von bioblend.galaxy import GalaxyInstance
      gi = GalaxyInstance(url='http://localhost:8080', key=)'
      HINWEIS: Dies funktioniert nur für lokale Deployments; wenn die Workflow-Engine auf einem entfernten Rechner bereitgestellt wird, ersetzen Sie den localhost durch die Adresse und den Port der konfigurierten Instanz.
   2. Verwenden Sie die Hilfsfunktionen in galaxy-api/helper_functs.py , um gängige Operationen auszuführen: verfügbare Workflows auflisten (get_workflows), Workflow-Eingabedefinitionen (get_inputs) abrufen und einen Workflow mit bestimmten Eingabedateien (launch_workflow) starten. Beziehen Sie sich auf die Inline-Docstrings in dieser Datei für Funktionssignaturen und erwartete Rückgabetypen.
   3. Erweitern Sie die helper_functs.py mit anderen Funktionen , wie von der Anwendung benötigt. Die vollständige Referenz-API finden Sie unter https://bioblend.readthedocs.io.
2. Workflows mit dem Metaverse verknüpfen
   HINWEIS: Dieser Abschnitt beschreibt nur die Architektur der Metaverse-Plattformerweiterung, sodass Entwickler sie für verschiedene Workflow-Ausgaben, zusätzliche Dateitypen oder alternative Metaverse-Plattformen anpassen können.
   1. Öffnen Sie den Haupteingang der Erweiterung in omni_exts/omni.galaxy.example/. Diese Erweiterung verwendet die Omniverse-Basiserweiterung¹⁵ als Ausgangspunkt. Anschließend fügt es alle Funktionen aus der in Schritt 5.1.2 beschriebenen API API hinzu und bietet eine GUI, um mit den Workflows zu interagieren.
   2. Wenn Workflows gestartet werden, werden die von ihnen erzeugten Daten automatisch aus der Workflow-Engine heruntergeladen und lokal gespeichert, sodass sie in der Metaverse-Plattform visualisiert werden können. Dies ermöglicht es auch, die während des Workflow-Laufs erzeugten Metadaten zu speichern und zugänglich zu machen, wodurch die Herkunft der Simulationsdaten bereitgestellt wird.
   3. Diese Implementierung verwendet die native omni.ui-Bibliothek von Omniverse, um die Schnittstelle zu erstellen. Die Haupterweiterung befindet sich im Erweiterungsordner, und die primäre Implementierung der Schnittstelle befindet sich in der Datei omni_exts/omni.galaxy.example/omni/galaxy/example/window.py .

Ergebnisse

Wenn die Simulationen mit den bereitgestellten Eingaben im Git-Repository ausgeführt werden, sollten folgende Ergebnisse erzielt werden:

Nach erfolgreichem Abschluss von Schritt 2.1.3 erscheinen sowohl die TBR - als auch die Track-Ausgabedaten grün im History-Panel , was einen erfolgreichen Durchlauf anzeigt. Ein repräsentativer TBR-Wert unter Verwendung der mitgelieferten Konfigurationsdatei (5 Chargen mit je...

Diskussion

Im Protokoll gibt es einige entscheidende Schritte. Die meisten betreffen die anfängliche Einrichtung der Workflow-Engine-Instanz, wie z. B. das Hinzufügen der Admin-E-Mail (Protokollschritt 1.2.2), da dies für den Admin-Zugriff auf die Werkzeug- und Jobs-Panels erforderlich ist; den API-Schlüssel korrekt für die Metaverse-Plattformerweiterung (Protokollschritt 1.5.3) zu erzeugen und diesen korrekt in die Standardwerte-Datei einzufügen; Und beim Hinzufügen von Werkzeugen, wobei sicherges...

Materialien

Liste der in diesem Artikel verwendeten Materialien

Name	Unternehmen	Katalognummer	Kommentare
Bioblend	Galaxy Project	v1.2+	Python-Bibliothek, die einen High-Level-Wrapper um die Galaxy REST API bereitstellt. Diese wird in den Omniverse-Erweiterungs-Hilfsprogrammen verwendet, um Workflows aufzulisten, Eingabedefinitionen abzurufen und Jobs zu starten. Wird automatisch in den entsprechenden Docker-Images installiert; keine Host-Installation erforderlich.
Docker Container	Docker	v24.0.5	Containerisierungsruntime zur Verpackung jeder Simulation und Nachbearbeitungs-Tool mit all ihren Abhängigkeiten, um Portabilität und Reproduzierbarkeit zu gewährleisten.
Galaxy	Galaxy Project	v22.05	Open-Source-Workflow-Engine, die verwendet wird, um die verketteten Simulations- und Verarbeitungstools zu orchestrieren und sie über eine REST-API verfügbar zu machen.
Git	Git SCM	v2+	Erforderlich, um das Repository zu klonen, um dem Protokoll zu folgen
NVIDIA RTX GPU	NVIDIA	-	Erforderlich für Echtzeit Ray-Traced Rendering in Omniverse (Abschnitt 3). Benutzer ohne RTX-Hardware können alle Schritte bis Abschnitt 2 abschließen und ParaView für die Visualisierung verwenden (siehe Diskussion).
Omniverse	NVIDIA	Code 2022.3.3	NVIDIAs kollaborative 3D-Plattform. Diese wird als Visualisierungs- und Interaktions-Frontend für Workflow-Ausgaben über eine benutzerdefinierte Kit-Erweiterung verwendet.
ParaView	Kitware	v5.11	Open-Source-Wissenschaftliche Visualisierungsanwendung, die als Nicht-RTX-Fallback zur Inspektion von Zwischen.vtk/.vtp-Ausgaben verwendet wird.
Protocol Repository	Custom	v1.0	Enthält Galaxy-Konfiguration zusammen mit allen Tool-XML-Wrappern, Ausführungsskripten, Dockerfiles, Testdaten und der Omniverse-Erweiterung. In Schritt 1.2.1 geklont. Wichtige Dateien werden auch als direkte ergänzende Uploads bereitgestellt (siehe I.2).
Python	Python	v3.10+	Laufzeit, die für das OpenMC-Ausführungsskript und die Omniverse-Erweiterungs-Hilfsprogramme erforderlich ist. Enthalten in den entsprechenden Docker-Images oder mit Omniverse-Download; keine separate Host-Installation erforderlich.
The OpenMC Monte Carlo Code	OpenMC	v0.13.3	Open-Source-Monte-Carlo-Partikeltransport-Code, der hier für Fusionsneutroniksimulation verwendet wird. Dies liefert das Tritium Breeding Ratio (TBR) und Neutronen-Track-Ausgaben.
Windows Subsystem für Linux (WSL)	Microsoft	v2	Erforderlich, um Docker auf Windows-Hosts auszuführen (Installieren über `wsl --install` in PowerShell). Linux- und Mac-Benutzer benötigen dies nicht.