Integración de flujos de trabajo automatizados de simulación con visualización 3D para experimentos virtuales en el Metaverso

Resumen

Se presenta un método generalizado y compatible con FAIR para investigadores expertos en dominio que buscan integrar herramientas de simulación y procesamiento de datos en flujos de trabajo automatizados para experimentos virtuales 3D. Un ejemplo de neutrónica demuestra cómo configurar una instancia local de Galaxy, envolver OpenMC y herramientas de conversión de archivos, lanzar flujos de trabajo desde Omniverse y visualizar las salidas convertidas en 3D.

Resumen

En muchos experimentos virtuales, se utilizan múltiples paquetes de software con diferentes tipos de simulación, herramientas de preprocesado y postprocesamiento, y herramientas para visualizar los resultados de los experimentos, a menudo una combinación de todos. El método típico de integración es manual, con soluciones a medida creadas para cada área de aplicación, lo que escala mal y dificulta el intercambio y la reproducibilidad.

Este protocolo demuestra el despliegue y uso de un sistema de flujo de trabajo localmente contenedorizado. Después, los usuarios lanzarán una instancia local de Galaxy usando Docker, crearán y ejecutarán un flujo de trabajo de simulación de neutrónica OpenMC, pasarán las salidas a través de una cadena de herramientas de conversión de formato y cargarán los resultados tanto en ParaView como en NVIDIA Omniverse para su visualización. El despliegue contenedor promueve la reproducibilidad y portabilidad en cualquier máquina que cumpla con los requisitos de hardware descritos en la Sección 1.

Una vez que el sistema está en funcionamiento, los flujos de trabajo pueden reejecutarse contra nuevas entradas sin necesidad de reconfiguración manual, códigos de simulación adicionales pueden envolverse como nuevas herramientas con un esfuerzo moderado, y las herramientas pueden usarse en múltiples flujos de trabajo y áreas de aplicación. El enfoque apoya los principios de datos encontrables, accesibles, interoperables y reutilizables (FAIR): los historiales de ejecución capturan metadatos completos de procedencia, los flujos de trabajo son exportables como archivos portátiles y pueden compartirse directamente entre instancias de Galaxy, y las herramientas se empaquetan en contenedores controlados por versiones que pueden publicarse en un repositorio público. La escalabilidad a recursos de computación de alto rendimiento (HPC) o en la nube mediante el sistema Pulsar de Galaxy es una extensión natural de la arquitectura descrita aquí.

El método se demuestra mediante un estudio de caso de neutrónica por fusión. OpenMC se utiliza para simular el transporte de neutrones en una geometría de diseño asistido por ordenador (CAD) de Geometría Acelerada Directa (DAGMC), produciendo un resultado de la relación de reproducción de tritio (TBR) y un conjunto de datos de seguimiento de neutrones. Los flujos de trabajo de simulación se conectan entonces a NVIDIA Omniverse como plataforma metaverso para la invocación y la visualización.

Introducción

El metaverso industrial combina mundos digitales y físicos para apoyar el diseño, la simulación y la visualización colaborativa en 3D de sistemas diseñados. Normalmente consistía en muchos gemelos digitales interconectados de componentes para ofrecer una visión global del sistema. Grandes organizaciones como Boeing, BMW, Amazon y muchas más están adoptando múltiples enfoques para crear^{metaversos 1}. Se han desarrollado y están utilizando sistemas para permitir múltiples cadenas de herramientas de simulación y procesamiento. Sin embargo, estos ejemplos suelen ser a medida para el área de aplicación² o son opciones^{comerciales 3 y 4} con cierta vinculación a sistemas propietarios. Se han utilizado algunas alternativas de código abierto para construir gemelos digitales para crear algunos sistemas, como Python Flask, con capacidades de simulación integradas. Aun así, estos se configuran como piezas de código a medida para realizar tareas específicas relacionadas con el modelo⁵ en particular. En el contexto de este protocolo, la plataforma metaverso (NVIDIA Omniverse) funciona como una interfaz de visualización 3D e interacción con flujos de trabajo: las salidas de la simulación se cargan en una escena compartida tras completar la ejecución del flujo de trabajo, y se pueden desencadenar nuevas ejecuciones desde el mismo entorno. Esto difiere de los sistemas digitales en vivo en los que las señales de sensores en tiempo real actualizan el modelo de forma continua; El método aquí demostrado soporta la ejecución por lotes de flujos de trabajo y la exploración posterior a la ejecución de los resultados. Sin embargo, esto se hace de tal manera que apoye futuros trabajos para integrar más sistemas en la plataforma del metaverso y permitir la creación de gemelos digitales con motores de flujo de trabajo como backend computacional.

Los flujos de trabajo pueden definirse como cadenas de herramientas de software que especifican explícitamente el flujo de datos entre ellas. Permiten envolver códigos de simulación existentes, scripts de procesamiento y otros pasos en una tubería típica de análisis, sin alterar su función, sino permitiendo que se configuren y reconfiguren con entradas y salidas estandarizadas que no dependen de la herramienta. Los flujos de trabajo permiten una fácil replicación de resultados mediante el intercambio de herramientas, proporcionando también metadatos y procedencia sobre qué versiones de herramientas se usaron, en qué orden y con qué entradas. Las propias herramientas pueden reutilizarse en muchas canaletas de simulación, permitiendo a los investigadores dedicar menos tiempo a preparar simulaciones y más tiempo diseñando experimentos y explorando los resultados. Los sistemas de flujo de trabajo también son escalables, con métodos para conectarse a diferentes recursos locales de computación, nube y HPC, lo que permite ejecutar muchos flujos de trabajo a gran escala en hardware específico de forma^{automatizada 6}.

El enfoque manual típico es inherentemente lento, propenso a errores y difícil de reproducir, en el que un investigador ejecuta manualmente cada herramienta de simulación o postprocesamiento, mueve archivos intermedios entre entornos y debe documentar las entradas y salidas de las ejecuciones individuales. En contraste, un gestor de flujos de trabajo formaliza el flujo de datos una vez y lo vuelve a ejecutar de forma determinista. Esto aporta muchos beneficios en comparación con los pipelines manuales: el mismo flujo de trabajo puede ejecutarse de forma idéntica en diferentes entradas, soportando estudios de parámetros sin scripting personalizado; Cada ejecución captura automáticamente todos los metadatos de procedencia, abordando cualquier brecha de reproducibilidad; Y una vez que una herramienta ha sido completada, su coste de reutilización en flujos de trabajo posteriores cae casi a cero, salvo el tiempo de cálculo. Estos beneficios han sido cuantificados para bioinformática por Wratten et ^al.7 y para proteómica/metabolómica por Perez-Riverol y^{Moreno 8} y Verhoeven et ^al.9.

Históricamente, los flujos de trabajo se han utilizado principalmente en el campo de la bioinformática ^8,9 con gran éxito en grandes instancias públicas como el servidor europeo^{Galaxy 10,11}, que para 2022 albergaba a más de 50.000 usuarios, 2.500 herramientas, ejecutaba más de 47 millones de trabajos y 260.000 ejecuciones de flujos de trabajo. La misma pila de motores de flujo de trabajo soporta escalar a recursos HPC y en la nube a través del sistema distribuido de ejecución de trabajos^{Pulsar 6,11}, con despliegues operativos que abarcan 13 endpoints Pulsar en 10 países europeos. Entre los muchos gestores de flujo de trabajo disponibles, incluyendo Snakemake, Nextflow, Toil y motores compatibles con CWL, el motor de flujo de trabajo^{Galaxy 11} fue seleccionado por varias razones. Una de las razones principales es su interfaz madura basada en navegador, que reduce la barrera de entrada para los expertos en el dominio que no trabajan principalmente en línea de comandos; expone una interfaz completa de programación de aplicaciones (API) para transferencia de estado representacional (REST) (utilizada en el trabajo actual para conectar con el front-end del metaverso); Su modelo de historia y empleos captura la procedencia en una forma que es fácil de revelar a colaboradores no especialistas; y soporta una descarga HPC transparente mediante el mencionado sistema Pulsar (aunque esto no se discute en la sección de protocolos de este artículo). Sin embargo, el enfoque descrito en este artículo es en principio independiente del motor de flujo de trabajo: integraciones equivalentes podrían construirse sobre motores alternativos. La contribución de este trabajo no es el gestor de flujos de trabajo en sí, sino la traducción de un gestor de flujos de trabajo de propósito general desarrollado originalmente para bioinformática a otros campos (con el ejemplo específico de la neutrónica de fusión aquí), y su integración con una plataforma industrial-metaverso (NVIDIA Omniverse), dentro de una pila totalmente contenedorizada y desplegable localmente, aplicada a experimentos virtuales 3D.

Finalmente, la contenedorización permite compartir muchas piezas de software empaquetando código con el sistema operativo y todas las dependencias que necesita para ejecutarse. Estos entornos evitan los problemas de dependencias perdidas y la molestia de instalar algunos códigos de simulación. Son similares en propósito a las máquinas virtuales, pero mucho más ligeras y portátiles. Aumentan drásticamente la capacidad de compartir y la reproducibilidad de los paquetes de software. En este método, el gestor de flujo de trabajo y las herramientas individuales se ejecutan en contenedores^{Docker 12} , aumentando la compatibilidad con diferentes sistemas operativos siempre que el usuario pueda ejecutar contenedores.

Este protocolo está destinado a investigadores expertos en dominio, por ejemplo, ingenieros de neutrónica de fusión, analistas de dinámica de fluidos computacional o practicantes de elementos finitos, que dominan las herramientas de simulación de su propio campo pero que no han utilizado previamente un gestor de flujo de trabajo ni un despliegue basado en contenedores. Se asume familiaridad con un único código de simulación y operación básica de línea de comandos; la familiaridad con Galaxy o el Omniverso no lo es. Los lectores nuevos en contenedorización deben consultar la documentación oficial de Docker (https://docs.docker.com/) o la formación introductoria disponible en: https://uomresearchit.github.io/docker-introduction/ antes de seguir la Sección 1; los comandos básicos necesarios para ejecutar el software están todos contenidos en el protocolo.

El resto de este informe cubrirá la configuración y el uso del sistema desplegable localmente. Luego, seguirá los pasos para desarrollar nuevas herramientas para el sistema y un método para vincular otros paquetes externos al motor de flujo de trabajo, como una plataforma metaverso. A lo largo del informe, una simulación de neutrónica utilizando OpenMC¹³ sirve como estudio de caso. OpenMC fue seleccionado porque demuestra toda la cadena de CAD, simulación y visualización de salida que motiva la arquitectura del flujo de trabajo. Un archivo de geometría y un archivo de configuración sirven como entradas estructuradas; la simulación de transporte de neutrones de Monte Carlo produce una métrica escalar (la relación de reproducción de tritio, TBR) que puede compararse con un rango conocido de valores, y un conjunto de datos de seguimiento de neutrones resuelto espacialmente que puede procesarse y presentarse en un formato visualizable para el renderizado 3D en la aplicación del metaverso.

Protocolo

NOTA: Una visión general de la configuración local del motor de flujo de trabajo, la construcción del flujo de trabajo, el lanzamiento del flujo de trabajo y los resultados de visualización se muestra en las Figuras 1, Figura 2, Figura 3, Figura 4, Figura 5, Figura 6, Figura 7 y Figura 8. Los archivos de repositorio necesarios para ejecutar el protocolo se proporcionan en el Archivo Suplementario 1.

1. Preparación

1. Requisitos
   NOTA: Este método ha sido probado en la última versión de Soporte a Largo Plazo (LTS) de Ubuntu, la 22.04.1 LTS. Otras versiones de Ubuntu y otras distribuciones pueden funcionar, pero no se han probado aquí. También funciona en sistemas Windows, utilizando Windows Subsystem for Linux (WSL) como backend de Docker.
   1. Usuarios de Windows: Descarguen WSL y configuren, ya que es un requisito para Docker.
   2. Descarga Docker y luego verifica ejecutando:
      `Hello-World dirigido por Docker'
      que debería mostrar un mensaje de bienvenida.
   3. Descarga el lanzador NVIDIA Omniverse y una de las aplicaciones de Omniverse a través del lanzador.
      NOTA: El renderizado ray-traced en tiempo real de NVIDIA Omniverse requiere una GPU de clase RTX. Los usuarios sin este hardware pueden seguir ejecutando el flujo de trabajo completo a través de la Sección 2 e inspeccionar las salidas intermedias .vtk / .vtp en ParaView (ver Discusión). Estos usuarios pueden saltarse la Sección 3, ya que solo se aplica a la plataforma del metaverso; Los métodos utilizados para integrar el motor de flujo de trabajo aquí pueden ser útiles si se conecta con otras plataformas del metaverso.
      Este protocolo utiliza la aplicación Omniverse Code, pero las otras aplicaciones de Omniverse deberían ser en general similares. Aunque no es esencial, ParaView puede usarse para visualizar algunos de los archivos intermedios producidos por las herramientas de este protocolo.
2. Repositorio
   1. Clona el repositorio que alberga todos los archivos y scripts necesarios para la instancia local del motor de flujo de trabajo y las herramientas descritas en este artículo con:
      'Git clone https://github.com/williamjsmith15/galaxy-omniverse-example.git'
   2. Añade un correo de administrador a la lista de usuarios administradores.
      NOTA: Esto otorgará los privilegios de administrador necesarios para algunas funciones del motor de flujo de trabajo y se puede encontrar en la sección admin_users del archivo galaxy-config/galaxy.yml (véase https://github.com/williamjsmith15/galaxy-omniverse-example/blob/master/galaxy-config/galaxy.yml).
   3. Renombra el archivo default.json.template a default.json. Este archivo está ubicado en omni_exts/omni.galaxy.example/omni/galaxy/example/default.json.template.
      NOTA: Esto permitirá que la extensión de la plataforma metaverso lo lea y que se añadan y persistan configuraciones personales entre cargas; se harán más cambios tras configurar la instancia de Galaxy.
3. Lanzamiento del Servidor Local del Motor de Flujo de Trabajo
   1. Lanza la instancia del motor de flujo de trabajo ejecutando el archivo start-galaxy.sh en el nivel superior del repositorio:
      './start-galaxy.sh'
      Si el archivo no se ejecuta aquí, puede que necesite hacerse ejecutable si los permisos han cambiado en el clon del repositorio. Esto se puede hacer ejecutando:
      'chmod a+x start-galaxy.sh'
      NOTA: Los usuarios de Windows deben hacerlo a través de su terminal WSL. Esto descargará los archivos relevantes y abrirá la instancia del motor de flujo de trabajo, que puede visualizarse en http://localhost:8080 en cualquier navegador que se ejecute en la misma máquina. Esto debería mostrar la página mostrada en la Figura 1; Si no, espera y actualiza: la instancia del motor de flujo de trabajo puede tardar en iniciarse (especialmente la primera vez).
      1. Generalmente, para ver los cambios realizados en el repositorio de la instancia del motor de flujo de trabajo, ejecuta './restart-galaxy.sh' o './stop-galaxy.sh' y luego inicia el script de nuevo.
4. Configuración de plataformas del Metaverso
   1. Abre la app después de descargar el lanzador y la app (para este ejemplo, Omniverse Code).
   2. En la parte superior izquierda de la ventana, haz clic en la pestaña Extensiones (en otras aplicaciones, esto estará bajo Ventana | Extensiones).
   3. En la ventana de extensiones , haz clic en el botón gris de configuración ; Mostrará una ventana con algunos directorios ya llenos. Añade otro que apunte a la carpeta omni_exts haciendo clic en el botón verde más y añade una ruta que tendrá el formato: '/ejemplo-galaxia-omniverso/omni_exts'; véase la Figura 2 para más detalles.
   4. Busca una nueva entrada llamada 'EJEMPLO DE GALAXIA OMNI' en la columna de la izquierda, bajo la pestaña TERCEROS PARTIDOS. Cambia el deslizador de esta extensión a activado y espera a que aparezca la ventana de extensión.
   5. Selecciona la casilla de carga automática para cargar la extensión automáticamente cada vez que se inicie la app.
      NOTA: Los cambios realizados en los archivos de extensión deben persistir automáticamente cuando el archivo se guarde, ya que Omniverse permite la recarga en caliente de extensiones
5. Creación de cuentas en el motor de flujo de trabajo y enlace al Metaverso
   1. En la instancia del motor de flujo de trabajo, crea una cuenta haciendo clic en el botón Iniciar sesión o Registrar en la barra superior, luego en Registrar aquí, y después rellenar los datos usando la dirección de correo añadida en el Paso 1.2.2 para crear una cuenta con acceso de administrador.
   2. Genera una clave API para que la API se comunique con el motor de flujo de trabajo. Ve al desplegable de Usuario en la barra superior | Preferencias | Gestionar clave API. Crea una clave y cópiala.
   3. Una vez generada la clave, añade esto al archivo de default.json creado en el paso 1.2.3 bajo el campo 'galaxy_api_key' en las comillas vacías.
      PRECAUCIÓN: Este archivo ahora contendrá una clave API. Esta clave API puede usarse para ejecutar trabajos y acceder a datos en la cuenta asociada. No debería ser un problema en un despliegue local donde no hay dominio público ni dirección IP; Este archivo debe seguir siendo considerado secreto y, por tanto, no compartirse ni comprometerse en un repositorio público (el archivo aparece por defecto en el .gitignore para combatir esto).
   4. Reinicia la app de la plataforma metaverso para actualizar los cambios realizados en el archivo por defecto.
      NOTA: La clave API también puede añadirse directamente a la ventana de extensión en el desplegable de configuración del servidor, aunque esto no persistirá entre sesiones.

2. Ejecutar trabajos en el Motor de Flujos de Trabajo

1. Herramientas individuales
   NOTA: Las herramientas individuales permiten ejecutar e inspeccionar pasos individuales de procesamiento o simulación de forma aislada, lo cual es útil para verificar que las entradas están correctamente formateadas y que una herramienta funciona como se espera antes de incorporarla a un flujo de trabajo. Los archivos de prueba referenciados a continuación, dagmc.h5m (la geometría CAD DAGMC) y openmc_config.json (la configuración de simulación), están en el directorio test_files del repositorio clonado.
   1. Sube los archivos de entrada necesarios haciendo clic en Upload Data en la columna izquierda y selecciona Elegir archivos locales o arrastra y suelta desde un explorador de archivos en esta ventana. Sube el dagmc.h5m (archivo CAD) y openmc_config.json (archivo de configuración), y luego haz clic en el botón Start para subir al historial actual. Ambos archivos aparecerán en verde en el panel de Historial a la derecha cuando se complete la carga.
   2. Selecciona el desplegable Herramientas Complejas en la columna izquierda de la página de inicio y luego la herramienta OpenMC Neutronics Simulation .
   3. Ahora, en la página específica de la herramienta, selecciona las entradas de los archivos que se subieron en el Paso 2.1.1 y selecciona el archivo CAD como el conjunto de datos dagmc.h5m y el archivo de configuración como el conjunto de datos openmc_config.json .
   4. Haz clic en el botón Ejecutar . Dos archivos nuevos (TBR y Tracks) aparecerán en el panel de Historia a la derecha de la pantalla. Se pondrán naranjas al funcionar y verdes cuando estén completas y tengan éxito, el rojo indicaría un fallo de la herramienta. Consulta la Sección 4 para los pasos de depuración.
   5. El valor TBR (ratio de reproducción de tritio) puede visualizarse para comprobar que el caso de prueba se ha ejecutado correctamente. Haz clic en la salida de la TBR para expandir, luego en el icono del gráfico y después en el editor. Esto mostrará el resultado de TBR, que debería estar alrededor de 0,76 (es un método estadístico, y la configuración aquí usa un tamaño de muestra pequeño para la velocidad de simulación, por lo que los resultados variarán).
      NOTA: El valor de TBR es estocástico; El valor de 0,76 puede variar en ±0,01 y esto refleja un recuento deliberadamente pequeño de partículas (5 lotes de 1.000 partículas) elegido para flujos de trabajo de ejemplo rápidos. Para reducir el rango de valores, aumenta el número de lotes y partículas bajo el campo de configuración del archivo openmc_config.json antes de volver a ejecutarlo. Como guía para una geometría simple como el caso presentado aquí, 50 lotes de 10.000 partículas deberían reducir la dispersión de los valores de TBR en las ejecuciones posteriores a costa de un tiempo de funcionamiento más largo.
   6. Otras herramientas pueden ejecutarse en la salida de Tracks del flujo de trabajo para procesar los resultados en postproducción. Ejecuta la herramienta Tracks h5 a vtp en la salida de Tracks y luego la herramienta CAD h5m a vtk en el archivo de entrada dagmc.h5m . Ambos producirán una única salida, tracks_0.vtp y dagmc.vtk, que los convierte en un formato más fácilmente visualizable.
   7. Las salidas producidas en el paso anterior pueden descargarse desde la instancia (haciendo clic en la salida y luego en el icono de guardado) y luego visualizarse en ParaView¹⁴ para ver las pistas simuladas de neutrones.
   8. Para visualizar los resultados en ParaView, importa las salidas descargadas de tracks_0.vtp y dagmc.vtk . Estos aparecerán en el lado izquierdo de la ventana. Haz clic en el icono de Ojo junto a los archivos importados, o en el botón Aplicar de abajo en la ventana de propiedades para visualizar la salida. Esto debería ser similar a lo que se ve en la Figura 7.
2. Flujos de trabajo
   NOTA: Un flujo de trabajo codifica una pipeline de procesamiento completa como un grafo dirigido de herramientas con entradas y salidas declaradas. Una vez definido, el mismo flujo de trabajo puede reejecutarse contra cualquier conjunto de archivos de entrada sin necesidad de reconfigurar manualmente cada herramienta, y todos los metadatos de historial de ejecución y procedencia se capturan automáticamente.
   1. Haz clic en Flujo de trabajo en la barra de navegación superior y luego en Crear en la esquina superior derecha. Introduce un nombre y una descripción para el flujo de trabajo (cualquier cosa sirve), luego haz clic en Crear de nuevo.
   2. Añadir tres herramientas al flujo de trabajo, ampliar las secciones relevantes en el menú de Herramientas y añadir las herramientas usadas en la sección 2.1: OpenMC Neutronics Simulation, CAD h5m a vtk y Tracks h5 a vtp.
   3. Define el flujo de datos entre las herramientas. Arrastra las herramientas por el espacio de trabajo haciendo clic y arrastrando la barra superior azul oscuro de cada una. Conecta la salida Tracks (h5) de la herramienta de simulación de neutrónica con la entrada tracks.h5 de la herramienta h5 a vtp. Haz esto haciendo clic y arrastrando desde la flecha de la salida hasta la flecha de la entrada.
   4. Define los conjuntos de datos de entrada a nivel de flujo de trabajo. En la sección de Entradas de las herramientas, haz dos veces clic en Conjunto de Datos de Entrada para crear dos nodos de entrada. Renombra uno para el archivo de configuración y otro para la entrada CAD haciendo clic en el paso y luego cambiando el campo Etiqueta en el menú de propiedades de la derecha.
   5. Vincula el archivo de configuración y el archivo CAD a las entradas de la herramienta de simulación de neutrónica, y el archivo CAD a la herramienta h5m a vtk, siguiendo el patrón de la Figura 3.
   6. Guarda el flujo de trabajo usando el icono de guardado en la esquina superior derecha.
   7. Para ejecutar el flujo de trabajo, haz clic en la pestaña Flujo de trabajo en la barra superior como antes, y luego haz clic en el icono de reproducir en el flujo de trabajo que se va a ejecutar. Luego selecciona las entradas como en el paso 2.1.2, igual que si ejecutas una herramienta, y haz clic en Ejecutar flujo de trabajo.
   8. Esperar a que se ejecute el flujo de trabajo, y entonces las salidas pueden compararse con los pasos 2.1.5 y 2.1.8; Estos deberían ser muy similares (de nuevo, fíjate en la variación estadística de estos pasos). El flujo de trabajo ha funcionado correctamente cuando todas las salidas en el Historial se han puesto verdes. Debería haber (junto con los conjuntos de datos de entrada) cuatro conjuntos de datos presentes: TBR, Tracks, dagmc.vtk y tracks_0.vtp.
   9. A medida que se ha ejecutado el flujo de trabajo, algunos usuarios pueden querer poder ver el origen y los metadatos capturados de la invocación (ejecutación) del flujo de trabajo. Esto se puede lograr navegando a Usuario en la barra superior | Invocaciones de flujo de trabajo. Esto da como resultado la lista de todos los flujos de trabajo ejecutados por el usuario, haz clic en la flecha descendente del flujo de trabajo de interés y luego puede descargar el archivo JSON de metadatos haciendo clic en el botón Descargar Objeto BioCompute . Esto contiene la procedencia de las herramientas/flujos de trabajo ejecutados, las entradas usadas, etc.
      NOTA: El motor de flujo de trabajo también registra un historial completo de ejecuciones para cada ejecución de flujo de trabajo, incluyendo sumas de comprobación de archivos de entrada, versiones de herramientas y valores de parámetros. Para descargar el registro de procedencia de una ejecución, abre el panel de Historial , haz clic en el menú (flecha hacia abajo) en la esquina superior derecha y selecciona Exportar Historial a Archivo. El archivo exportado contiene todos los conjuntos de datos y un registro legible por máquina de los pasos que los generaron.
      El guardado de procedencia o historiales generados por el motor de flujo de trabajo puede automatizarse mediante la API discutida en la Sección 5.1; sin embargo, no se detallará en este protocolo.
3. Flujo de trabajo más complejo
   NOTA: Este flujo de trabajo amplía la Sección 2.2 añadiendo pasos de postprocesamiento que generan archivos de Descripción Universal de Escenas (USD) necesarios para la visualización en la plataforma metaverso. Como ninguna herramienta convierte directamente de DAGMC (.h5m) o VTK (vtp) a USD, la tubería enruta los datos a través de dos cadenas de conversión de varios pasos: la geometría CAD sigue una tubería H5M, STL, OBJ, USD, y las pistas de neutrones siguen H5, VTP, OBJ, USD.
   1. Sigue los pasos para establecer un flujo de trabajo, como se muestra en la sección 2.2, siguiendo el flujo de trabajo mostrado en la Figura 4.
   2. Define las dos entradas a nivel de flujo de trabajo como en el paso 2.2.4, nombrándolas CAD DAGMC y Archivo de Configuración.
   3. Añade la herramienta OpenMC Neutronics Simulation y conecta las entradas CAD DAGMC y Config File a sus entradas correspondientes, como en el paso 2.2.3.
   4. Crea la cadena de conversión neutrónica. Añade las herramientas de pistas h5 a vtp, vtp a obj y obj a USD y luego conecta las salidas de cada una a las entradas de la siguiente, siguiendo la disposición en la rama inferior de la Figura 4.
   5. Crea la cadena de conversión CAD. Suma las herramientas h5m a STL, STL a OBJ y OBJ a USD, y luego conecta de nuevo las salidas de cada una con las entradas de la siguiente, siguiendo el diseño en la rama superior de la Figura 4.
   6. Guarda el flujo de trabajo, que ya está listo para usarse en la plataforma del metaverso a través de la extensión de la Sección 3.
      NOTA: Estos pasos adicionales muestran a los usuarios cómo se pueden compartir flujos de trabajo y herramientas, permitiendo la reproducibilidad y accesibilidad a los datos y métodos utilizados para generar resultados.
   7. Exporta el flujo de trabajo como un archivo portátil navegando a Flujo de trabajo en la barra superior, haciendo clic en el menú (flecha hacia abajo) y seleccionando Descargar. El gestor de flujos de trabajo guarda un archivo JSON .ga , que luego puede ser compartido y utilizado por cualquiera con las mismas herramientas en su instancia del motor de flujo de trabajo. Esto se puede importar mediante Flujo de trabajo en la barra superior | Importar.
   8. Comparte herramientas haciendo commit de la carpeta galaxy-tools/ del repositorio clonado en un host público de control de versiones. Pide a los colaboradores que clonen esto para acceder a todas las herramientas contenedoras, ejecutándolas de la misma manera que en el dispositivo local del editor.
      NOTA: Se pueden configurar instancias públicas de gestores de flujos de trabajo, lo que evita el intercambio manual de archivos de flujo de trabajo y herramientas entre despliegues locales. En estos casos, las herramientas son accesibles para todos los usuarios, y los flujos de trabajo e historiales pueden hacerse públicos para todos los demás usuarios. Esto está fuera del alcance de este protocolo, pero se puede encontrar más información en la red oficial de Galaxy Training para obtener un despliegue permanente: https://training.galaxyproject.org/training-material/topics/admin/tutorials/ansible-galaxy/tutorial.html o la pila de composición docker proporcionada en el repositorio pueden desplegarse tal cual en un servidor y luego enrutarse mediante un proxy o medios similares para hacerlo accesible públicamente.

3. Ejecutar un flujo de trabajo desde la plataforma del metaverso

1. Lanzamiento del flujo de trabajo
   1. En la ventana de extensión de la plataforma metaverso, haz clic en Obtener flujos de trabajo (anotación 2, Figura 5). Un desplegable se llenará con todos los flujos de trabajo disponibles en la cuenta del motor de flujo de trabajo asociada a la clave API almacenada en default.json. Si no es así, comprueba que la clave API se ha guardado correctamente en el archivo JSON y reinicia la aplicación de la plataforma metaverso para asegurarte de que recoge la clave.
   2. Selecciona el Flujo de Trabajo Complejo para la lista y luego haz clic en Obtener Entradas (anotación 4, Figura 5). Los campos de entrada definidos en el flujo de trabajo (Paso 2.3.2) aparecerán y deben tener el mismo nombre.
   3. Para cada entrada basada en archivos, haz clic en Select File y utiliza la ventana emergente del explorador de archivos para seleccionar el archivo local correspondiente: dagmc.h5m para la entrada CAD DAGMC y openmc_config.json para la entrada de Config File .
   4. Haz clic en Iniciar flujo de trabajo (anotación 6, Figura 5). Se mostrará un mensaje de confirmación de lanzamiento en la sección de Información (anotación 7). Una vez completado el flujo de trabajo, mensajes adicionales confirmarán que los archivos de salida se han guardado y que la ejecución ha finalizado.
      NOTA: El progreso de los trabajos del flujo de trabajo puede monitorizarse en la interfaz web del motor de flujo de trabajo a http://localhost:8080 navegando a Admin | Empleos. Se requiere acceso de administrador (véase el paso 1.2.2).
2. Visualización de los resultados
   NOTA: Al completar cada ejecución de flujo de trabajo, el sistema descarga automáticamente los archivos de salida del motor de flujo de trabajo a un directorio de salida local. La ruta de guardado está controlada por la tecla output_dir en el archivo default.json de la extensión. Cada ejecución se almacena en una carpeta con marca de tiempo, por lo que las salidas pueden distinguirse por la extensión. Si hay problemas de visualización en la plataforma metaverso, los archivos pueden accederse a estas carpetas y consultarse manualmente para ver si el problema está en el motor de flujo de trabajo.
   1. En la plataforma metaverso, amplía la sección Administrador de archivos (anotación 1, Figura 6) y haz clic en Actualizar (anotación 2). Esto recupera la lista de las ejecuciones de flujo de trabajo completadas guardadas en el directorio local.
   2. En el desplegable de Carpetas (anotación 3, Figura 6), selecciona la carpeta para la ejecución actual del flujo de trabajo (confirma que es la única que existe actualmente) y haz clic en Actualizar de nuevo para rellenar el desplegable de Archivos con las salidas de esa ejecución.
   3. Selecciona un archivo desde el desplegable Archivos (anotación 4, Figura 6; actualmente solo se admiten archivos .usd, .txt, .json y .out ) y luego haz clic en Pull File (anotación 5). Los archivos basados en texto se muestran en el panel de Información , los archivos USD se añaden a la escena actual y deben visualizarse en la ventana principal de visualización.
   4. Para alinear la geometría importada con la convención de coordenadas de Omniverse, abre el panel de Etapa a la derecha, selecciona ambos objetos de flujo de trabajo importados y, en el panel de Propiedades justo debajo, pon Rotar X a −90°. Esto corrige la descoordinación entre la convención z-up usada por las herramientas de exportación en USD y la convención y-up de Omniverse. Aplica esta rotación tanto al CAD USD como al archivo USD de las pistas; el estado esperado del visor tras la alineación se muestra en la Figura 8.
   5. Finalmente, para conseguir más contraste entre las piezas, se pueden asignar materiales. Esto se consigue abriendo la pestaña de Materiales en la parte inferior de la aplicación, seleccionando un material y luego arrastrando y soltando la geometría en la vista de escenario en la columna derecha. Haz esto para ambas geometrías importadas para aumentar el contraste entre ellas.

4. Incorporación de nuevas herramientas

NOTA: Esta sección describe el proceso de desarrollo para crear y desplegar nuevas herramientas de flujo de trabajo. Requiere acceso al sistema de archivos del repositorio y acceso de administrador al motor de flujo de trabajo para la depuración. Los usuarios que solo necesitan ejecutar herramientas y flujos de trabajo existentes, o crear flujos de trabajo, no tienen que seguir esta sección.

1. Proceso general
   1. Desarrolla y prueba el script de simulación o procesamiento independientemente del motor de flujo de trabajo antes de envolverlo. El envoltorio de herramientas llama a un script de trabajo existente, no se recomienda implementar nueva lógica mientras se desarrolla una herramienta.
   2. Prepara el entorno de ejecución del script creando una imagen Docker que incluya todas las dependencias de ejecución (librerías, binarios, archivos de datos, etc.) requeridas por el script.
      NOTA: Todas las herramientas de ejemplo en este protocolo utilizan contenedores Docker como entorno de ejecución. Los entornos Conda también son compatibles con el motor de flujo de trabajo, pero no se muestran aquí. Más información sobre Docker puede encontrarse en la documentación oficial, o un buen curso introductorio aquí: https://uomresearchit.github.io/docker-introduction/ .
   3. Crea un archivo de definición de herramienta XML que declare el entorno de ejecución (Docker en este caso), el comando para invocar el script, y las entradas, salidas y metadatos de las herramientas para mostrarlos en la interfaz del motor de flujo de trabajo.
   4. Una vez creado el envoltorio, coloca el XML y cualquier script en una nueva carpeta galaxy-tools// dentro del repositorio. Añade una nueva entrada para la herramienta en galaxy-tools/tool_conf.xml bajo las etiquetas correspondientes , apuntando a la ruta relativa del archivo XML recién creado.
      NOTA: Asegúrese de copiar exactamente este nombre de archivo, ya que es un error común al intentar desplegar nuevas herramientas. Si la entrada tool_conf.xml contiene una ruta incorrecta o el archivo XML tiene un error de sintaxis, la instancia del motor de flujo de trabajo no se iniciará. Para inspeccionar los registros del contenedor del flujo de trabajo en busca de mensajes de error, ejecuta lo siguiente desde la raíz del repositorio:
      'docker compone logs galaxy'
      Los errores de análisis XML aparecen como líneas de la herramienta de carga ERROR del formulario
   5. Redeploya el motor de flujo de trabajo para cargar la nueva herramienta ejecutando el script de reinicio desde la raíz del repositorio: ./restart-galaxy.sh.
   6. Confirma que la herramienta ha sido registrada correctamente. Navega a http://localhost:8080, localiza la herramienta en el panel de Herramientas y haz clic en ella para asegurarte de que todas las entradas aparecen como se espera. Si la herramienta está ausente, sigue la nota anterior para la depuración y, si aún hay errores, revisa la sintaxis del propio XML de la herramienta, ya que esto también puede causar errores de despliegue.
   7. Ejecuta la nueva herramienta como antes, pero con entradas que ya se hayan probado previamente. Las salidas deberían ponerse verdes en el panel de Historia
   8. Si las herramientas fallan, como administrador, haz clic en la salida fallida (roja) y luego en el icono de Información . Esto muestra una página de salida detallada y muestra los flujos stdout y stderr. Estos pueden ampliarse para obtener más información sobre cómo depurar la herramienta.
2. Herramientas sencillas
   NOTA: Las herramientas 1–5 ilustran patrones de envolvimiento progresivamente más complejos. El archivo XML y cualquier script para cada herramienta están en el subdirectorio correspondiente galaxy-tools/simple/ / del repositorio. Despliega y ejecuta cada herramienta siguiendo los pasos 4.1.4–4.1.5 y la Sección 2.1.
   Herramienta 1 – Ejecutar un comando sencillo
   1. Mira el archivo galaxy-tools/simple/1/1.xml . El elemento de requisitos especifica un entorno de ejecución Linux. El elemento de comando contiene el comando de eco para ejecutar.
   2. Ejecuta la Herramienta 1 desde la interfaz del motor de flujo de trabajo sin necesidad de archivos de entrada. Como tampoco hay archivos de salida definidos, como administrador, ve a la página de Administrador, Trabajos y luego haz clic en el icono de Información para ver los flujos stdout y stderr, que es el mismo que en el paso 4.1.8. El flujo stdout debería contener solo la cadena 'hello world' del comando en el archivo XML.
      Herramienta 2 – Uso de entrada basada en texto
   3. Mira el archivo galaxy-tools/simple/2/2.xml . Ahora hay una entrada en el campo de entrada, con un elemento param de type="text" y la sección de comandos ahora hace referencia a la variable de entrada mediante la etiqueta de nombre.
   4. Ejecuta la Herramienta 2 como antes; Esta vez, dale a la herramienta una entrada de cuerda. Esto puede ser cualquier cosa que el usuario desee. Ve la salida como en el Paso 4.2.2, y la salida estándar debe ser la cadena que el usuario proporcionó en la entrada de la herramienta.
      Herramienta 3 – Uso de una entrada basada en archivos
   5. De nuevo, mira el archivo de herramientas; Ahora, en lugar de una entrada de cadena, el parámetro de entrada utiliza una etiqueta type="data", que permite el uso de un archivo. Esto se menciona en la sección de comandos como ruta de archivo, usando nuevamente el nombre del parámetro de entrada.
   6. Crea un archivo .txt usando un editor de texto local, si no ejecuta:
      'eco de "hola mundo desde un archivo" > test_files/input.txt'
      desde la carpeta raíz del repositorio para generar la entrada de ejemplo.
   7. Sube el archivo de .txt creado como en el paso 2.1.1 y luego ejecuta la Herramienta 3 como antes, seleccionando el archivo de .txt subido como entrada. De nuevo, mira el stdout de la misma manera y el contenido del archivo .txt debería mostrarse allí. Si se usa el comando anterior, la salida debería ser "hello world from a file".
      Herramienta 4 – Escribir la salida en un archivo
   8. Consulta galaxy-tools/simple/4/4.xml. Una sección de salidas ahora declara un archivo de salida con nombre que puede ser referenciado en la sección de comandos .
   9. Ejecuta la herramienta como antes con la entrada .txt , pero ahora, en lugar de ver la salida como administrador, el usuario habitual puede verla en este panel de Historial , y si se ejecuta con éxito, se pondrá verde y podrá descargarse o visualizarse en el motor de flujo de trabajo como se detalló en secciones anteriores.
      Herramienta 5 – Ejecutar scripts en herramientas
   10. Examina galaxy-tools/simple/5/5.xml y el script de python correspondiente galaxy-tools/simple/5/5.py. En el XML, el comando hace referencia al script Python del directorio de herramientas, y la sección de requisitos ahora hace referencia a una imagen Python ya que Python es necesario para ejecutar el script.
   11. Despliega y ejecuta la herramienta de la misma manera, y debería comportarse igual que la Herramienta 4 (Paso 4.2.9), excepto que esta vez ejecuta un script en lugar del comando directamente.
3. Ejemplo de herramienta compleja
   NOTA: Esta sección documenta el desarrollo de la herramienta de neutrónica como ejemplo práctico del patrón descrito en la Sección 4.1. Los archivos relevantes están en galaxy-tools/complex/openmc/. El mismo patrón se generaliza a cualquier código de simulación o procesamiento.
   1. Desarrolla el script de ejecución para la simulación. Para este ejemplo, el script run galaxy-tools/complex/openmc/openmc_run.py analiza un archivo de configuración (openmc_config.json), escribe el archivo de configuración de neutrónica y ejecuta la simulación. Prueba el script directamente desde la línea de comandos antes de incluirlo en una imagen Docker.
   2. Construye el entorno de ejecución de Docker usando el Dockerfile en galaxy-tools/complex/openmc/Dockerfile. Esto amplía la imagen pública con algunos paquetes adicionales. Compila y etiquétalo localmente o consulta desde un registro de contenedores.
   3. Crea el wrapper XML galaxy-tools/complex/openmc/openmc.xml, declarando la imagen Docker del paso 4.3.2 en la sección de requisitos . También debe definirse el comando para ejecutarse junto con los archivos de entrada y salida (como en el ejemplo de la Sección 4.2).
   4. Despliega la herramienta como en los pasos 4.1.4-4.1.7 y luego utiliza las entradas de prueba usadas en la Sección 2 para asegurarte de que la herramienta funciona correctamente.
      NOTA: Las herramientas restantes en la instancia (pistas h5 a vtp, CAD h5m a vtk, h5m a stl, stl a obj, vtp a obj, obj a USD) son convertidores de formato de archivo que siguen el mismo patrón de desarrollo. Sus archivos XML están en galaxy-tools/complex/ directorio y pueden servir como ejemplos de referencia adicionales.

5. Conectar flujos de trabajo con el Metaverso

NOTA: Esta sección proporciona material de referencia para desarrolladores que describe la integración de la API del motor de flujo de trabajo y la arquitectura de la extensión de la plataforma metaverso. Los usuarios que solo necesiten ejecutar flujos de trabajo desde la plataforma del metaverso deben seguir la Sección 3 y no tener que leer esta sección. Los desarrolladores que deseen conectar una aplicación de interfaz diferente al motor de flujo de trabajo deben comenzar desde la Sección 5.1.

1. API del motor de flujo de trabajo
   NOTA: Galaxy expone una API RESTful. La biblioteca Bioblend Python proporciona un envoltorio de nivel superior alrededor de esta API y es la base de todos los scripts auxiliares usados en este protocolo. Bioblend se instala automáticamente dentro de los entornos de ejecución Docker relevantes proporcionados en el repositorio.
   1. Importa Bioblend y establece una conexión con el motor de flujo de trabajo en ejecución instanciando un objeto GalaxyInstance con la dirección del servidor y la clave API del paso 1.5.2. En Python en un entorno con Bioblend instalado:
      `de bioblend.galaxy importación GalaxyInstance
      gi = GalaxyInstance(url='http://localhost:8080', key=)'
      NOTA: Esto solo funcionará para despliegues locales; si el motor de flujo de trabajo está desplegado en una máquina remota, sustituye el localhost por la dirección y el puerto de la instancia configurada.
   2. Utiliza las funciones auxiliares en galaxy-api/helper_functs.py para realizar operaciones comunes: listar flujos de trabajo disponibles (get_workflows), recuperar definiciones de entrada de flujo de trabajo (get_inputs) y lanzar un flujo de trabajo con archivos de entrada especificados (launch_workflow). Consulta las docstrings en línea de ese archivo para firmas de funciones y tipos de retorno esperados.
   3. Extiende la helper_functs.py con otras funciones según lo requiera la aplicación. La API de referencia completa se puede encontrar en https://bioblend.readthedocs.io.
2. Vinculación de flujos de trabajo al metaverso
   NOTA: Esta sección solo describe la arquitectura de la extensión de la plataforma metaverso para que los desarrolladores puedan adaptarla a diferentes salidas de flujo de trabajo, tipos de archivo adicionales o plataformas alternativas de metaverso.
   1. Abre el punto de entrada principal de la extensión en omni_exts/omni.galaxy.example/. Esta extensión utiliza la extensión base¹⁵ de Omniverse como punto de partida. Luego añade toda la funcionalidad del archivo API Python de funciones auxiliares descrito en el paso 5.1.2 y proporciona una interfaz gráfica para interactuar con los flujos de trabajo.
   2. Cuando se lanzan flujos de trabajo, los datos que generan se descargan automáticamente desde el motor de flujo de trabajo y se almacenan localmente, permitiendo visualizarlos en la plataforma del metaverso. Esto también permite guardar y hacer accesibles los metadatos generados durante la ejecución del flujo de trabajo, proporcionando así la procedencia de los datos de simulación.
   3. Esta implementación utiliza la biblioteca nativa omni.ui de Omniverse para construir la interfaz. La extensión principal está en la carpeta de extensiones, y la implementación principal de la interfaz está en el archivo omni_exts/omni.galaxy.example/omni/galaxy/example/window.py .

Resultados

Si las simulaciones se ejecutan con las entradas proporcionadas en el repositorio git, se deben obtener los siguientes resultados:

Al completar con éxito el Paso 2.1.3, tanto los conjuntos de datos de lectura por leer pendientes como los de Pistas aparecerán en verde en el panel de Historia , indicando una ejecución exitosa. Un valor representativo de TBR usando el archivo de configuración suministrado (5 lote...

Discusión

Hay algunos pasos críticos dentro del protocolo. La mayoría se refieren a la configuración inicial de la instancia del motor de flujo de trabajo, como: añadir el correo de administrador (paso de protocolo 1.2.2), ya que es necesario para el acceso de administrador a los paneles de herramientas y trabajos; generar correctamente la clave API para la extensión de la plataforma del metaverso (paso de protocolo 1.5.3) y pegar esto correctamente en el archivo de valores por defecto; Y al añadi...

Materiales

Lista de materiales utilizados en este artículo

Nombre	Empresa	Número de catálogo	Comentarios
Bioblend	Galaxy Project	v1.2+	Biblioteca de Python que proporciona un envoltorio de alto nivel alrededor de la API REST de Galaxy. Esto se utiliza en los scripts de ayuda de la extensión Omniverse para listar flujos de trabajo, recuperar definiciones de entrada y lanzar trabajos. Se instala automáticamente dentro de las imágenes de Docker relevantes; no se requiere instalación en el host.
Contenedores Docker	Docker	v24.0.5	Runtime de contenedorización utilizado para empaquetar cada simulación y herramienta de posprocesamiento con todas sus dependencias, asegurando la portabilidad y la reproducibilidad.
Galaxy	Galaxy Project	v22.05	Motor de flujo de trabajo de código abierto utilizado para orquestar las herramientas encadenada de simulación y procesamiento y exponerlas a través de una API REST.
Git	Git SCM	v2+	Requerido para clonar el repositorio para seguir el protocolo
NVIDIA RTX GPU	NVIDIA	-	Requerido para el renderizado en tiempo real con trazado de rayos en Omniverse (Sección 3). Los usuarios sin hardware RTX pueden completar todos los pasos hasta la Sección 2 y usar ParaView para la visualización (ver Discusión).
Omniverse	NVIDIA	Code 2022.3.3	Plataforma 3D colaborativa de NVIDIA. Se utiliza como la interfaz de visualización e interacción para los resultados del flujo de trabajo a través de una extensión personalizada de Kit.
ParaView	Kitware	v5.11	Aplicación de visualización científica de código abierto utilizada como alternativa para no-RTX para inspeccionar salidas intermedias .vtk/.vtp.
Repositorio del Protocolo	Personalizado	v1.0	Contiene la configuración de Galaxy junto con todos los envoltorios XML de herramientas, scripts de ejecución, Dockerfiles, datos de prueba y la extensión de Omniverse. Clonado en el Paso 1.2.1. Los archivos clave también se proporcionan como cargas suplementarias directas (ver I.2).
Python	Python	v3.10+	Runtime requerido para el script de ejecución de OpenMC y los scripts de ayuda de la extensión de Omniverse. Incluido dentro de las imágenes de Docker relevantes o con la descarga de Omniverse; no se requiere instalación separada en el host.
El Código Monte Carlo OpenMC	OpenMC	v0.13.3	Código de transporte de partículas Monte Carlo de código abierto utilizado aquí para simulación de fusión de neutrones. Esto proporciona la razón de reproducción de tritio (TBR) y las salidas de seguimiento de neutrones.
Windows Subsystem for Linux (WSL)	Microsoft	v2	Requerido para ejecutar Docker en hosts de Windows (instalar vía `wsl --install` en powershell). Los usuarios de Linux y Mac no necesitan esto.