Integrando Fluxos de Trabalho Automatizados de Simulação com Visualização 3D para Experimentos Virtuais no Metaverso

Resumo

Um método generalizado, compatível com FAIR, é apresentado para pesquisadores especialistas em domínio que buscam integrar ferramentas de simulação e processamento de dados em fluxos de trabalho automatizados para experimentos virtuais 3D. Um exemplo de neutrônica demonstra como configurar uma instância Galaxy local, envolver OpenMC e ferramentas de conversão de arquivos, iniciar fluxos de trabalho a partir do Omniverse e visualizar as saídas 3D convertidas.

Resumo

Em muitos experimentos virtuais, múltiplos pacotes de software são usados com vários tipos de simulação, ferramentas de pré e pós-processamento, e ferramentas para visualizar os resultados dos experimentos — frequentemente uma combinação de todos. O método típico de integração é manual, com soluções personalizadas criadas para cada área de aplicação, o que escala mal e dificulta o compartilhamento e a reprodutibilidade.

Esse protocolo demonstra a implantação e o uso de um sistema de fluxo de trabalho localmente conteinerizado. Após isso, os usuários iniciarão uma instância Galaxy local usando o Docker, criarão e executarão um fluxo de trabalho de simulação de neutrônica OpenMC, passarão as saídas por uma cadeia de ferramentas de conversão de formato e carregarão os resultados tanto no ParaView quanto no NVIDIA Omniverse para visualização. A implantação conteinerizada promove a reprodutibilidade e portabilidade em qualquer máquina que atenda aos requisitos de hardware descritos na Seção 1.

Uma vez que o sistema está em execução, fluxos de trabalho podem ser reexecutados contra novas entradas sem necessidade de reconfiguração manual, códigos adicionais de simulação podem ser incorporados como novas ferramentas com esforço modesto, e ferramentas podem ser usadas em múltiplos fluxos de trabalho e áreas de aplicação. A abordagem suporta os princípios de dados encontráveis, acessíveis, interoperáveis e reutilizáveis (FAIR): históricos de execução capturam metadados completos de procedência, fluxos de trabalho são exportáveis como arquivos portáteis e podem ser compartilhados diretamente entre instâncias da Galaxy, e ferramentas são empacotadas em contêineres controlados por versão que podem ser publicados em um repositório público. A escalabilidade para computação de alto desempenho (HPC) ou recursos em nuvem via o sistema Pulsar da Galaxy é uma extensão natural da arquitetura descrita aqui.

O método é demonstrado por meio de um estudo de caso de neutrônica de fusão. O OpenMC é usado para simular o transporte de nêutrons em uma geometria de design assistido por computador (CAD) com Geometria Acelerada Direta (DAGMC), produzindo um resultado de razão de reprodução de trítio (TBR) e um conjunto de dados de trilha de nêutrons. Os fluxos de trabalho de simulação são então conectados ao NVIDIA Omniverse como plataforma de metaverso para invocação e visualização.

Introdução

O metaverso industrial combina mundos digitais e físicos para apoiar o design, simulação e visualização colaborativa 3D de sistemas engenheirados. Normalmente, consistia em muitos gêmeos digitais interconectados de componentes para oferecer uma visão geral do sistema. Grandes organizações como Boeing, BMW, Amazon e muitas outras estão adotando múltiplas abordagens para criar^{metaversos 1}. Sistemas para permitir múltiplas cadeias de ferramentas de simulação e processamento foram desenvolvidos e estão sendo utilizados. No entanto, esses exemplos normalmente são personalizados para a área de aplicação² ou são opções^{comerciais 3,4} com algum vínculo com sistemas proprietários. Algumas alternativas de código aberto para construir gêmeos digitais foram usadas para criar alguns sistemas, como o Python Flask, com capacidades de simulação integradas. Ainda assim, esses são configurados como pedaços de código personalizados para realizar tarefas específicas relacionadas ao modelo⁵ em questão. No contexto desse protocolo, a plataforma metaverso (NVIDIA Omniverse) funciona como uma interface de visualização 3D e interação de fluxo de trabalho: as saídas de simulação são carregadas em uma cena compartilhada após a conclusão de uma execução de workflow, e novas execuções podem ser acionadas dentro do mesmo ambiente. Isso difere dos sistemas de gêmeos digitais ao vivo, nos quais os sensores em tempo real atualizam o modelo continuamente; O método demonstrado aqui suporta execução de fluxo de trabalho em lote e exploração pós-execução dos resultados. No entanto, isso é feito de forma a apoiar trabalhos futuros para integrar mais sistemas à plataforma do metaverso, permitindo a criação de gêmeos digitais com motores de fluxo de trabalho como backend computacional.

Fluxos de trabalho podem ser definidos como cadeias de ferramentas de software que especificam explicitamente o fluxo de dados entre elas. Eles permitem o encapsulamento de códigos de simulação existentes, scripts de processamento e outras etapas em um pipeline típico de análise, sem alterar a função destes, mas permitindo que sejam configurados e reconfigurados com entradas e saídas padronizadas que são independentes da ferramenta. Fluxos de trabalho permitem a fácil replicação dos resultados por meio do compartilhamento de ferramentas, além de fornecer metadados e proveniência sobre quais versões das ferramentas foram usadas, em que ordem e com quais entradas. As próprias ferramentas podem ser reutilizadas em muitos pipelines de simulação, permitindo que pesquisadores gastem menos tempo configurando simulações e mais tempo projetando experimentos e explorando os resultados. Os sistemas de fluxo de trabalho também são escaláveis, com métodos para se conectar a diferentes recursos locais de computação, nuvem e HPC, permitindo que muitos fluxos de trabalho de grande escala sejam executados em hardware específico de forma^{automatizada 6}.

A abordagem manual típica é inerentemente lenta, propensa a erros e difícil de reproduzir, na qual um pesquisador executa manualmente cada ferramenta de simulação ou pós-processamento, move arquivos intermediários entre ambientes e precisa documentar entradas e saídas de execução individuais. Em contraste, um gerente de workflow formaliza o fluxo de dados uma vez e o executa novamente deterministicamente. Isso traz muitos benefícios em relação aos pipelines manuais: o mesmo fluxo de trabalho pode ser executado idênticamente em diferentes entradas, suportando estudos de parâmetros sem scripts personalizados; cada execução captura automaticamente todos os metadados de proveniência, abordando qualquer lacuna de reprodutibilidade; E, uma vez que uma ferramenta está pronta, seu custo de reutilização em fluxos de trabalho subsequentes cai para quase zero, exceto no tempo de computação. Esses benefícios foram quantificados para bioinformática por Wratten et ^al.7 e para proteômica/metabolômica por Perez-Riverol e^{Moreno 8} e Verhoeven et ^al.9.

Historicamente, fluxos de trabalho têm sido usados principalmente na área de bioinformática ^8,9 com grande sucesso em grandes instâncias públicas como o servidor europeu^{Galaxy 10,11}, que até 2022 hospedava mais de 50.000 usuários, 2.500 ferramentas, executava mais de 47 milhões de trabalhos e 260.000 execuções de fluxos de trabalho. A mesma pilha de motores de fluxo de trabalho suporta escalabilidade para recursos HPC e nuvem via o sistema distribuído de execução de tarefas^{Pulsar 6,11}, com implantações operacionais abrangendo 13 endpoints Pulsar em 10 países europeus. Entre os muitos gerenciadores de workflow disponíveis, incluindo Snakemake, Nextflow, Toil e motores compatíveis com CWL, o Galaxy workflow^{engine 11} foi selecionado por alguns motivos. Uma das principais razões é sua interface madura baseada em navegador, que reduz a barreira de entrada para especialistas em domínio que não atuam principalmente na linha de comando; ele expõe uma interface completa de programação de aplicações (API) para transferência de estado representacional (REST) (usada no presente trabalho para fazer a ponte para a front-end do metaverso); seu modelo de história e empregos captura a proveniência de uma forma que é fácil de revelar a colaboradores não especialistas; e suporta descarregamento HPC transparente via o mencionado sistema Pulsar (embora isso não seja discutido na seção de protocolo deste artigo). A abordagem descrita neste artigo, no entanto, é em princípio independente do mecanismo de fluxo de trabalho: integrações equivalentes poderiam ser construídas sobre motores alternativos. A contribuição desse trabalho não é o gerenciador de fluxo de trabalho em si, mas a tradução de um gerenciador de fluxo de trabalho de uso geral originalmente desenvolvido para bioinformática para outros campos (com o exemplo específico da neutronia de fusão aqui), e sua integração com uma plataforma de metaverso industrial (NVIDIA Omniverse), dentro de uma pilha totalmente conteinerizada e localmente implantável, aplicada a experimentos virtuais 3D.

Por fim, a containerização permite o compartilhamento de muitos softwares ao empacotar código com o sistema operacional e todas as dependências necessárias para rodar. Esses ambientes evitam problemas de dependências ausentes e o incômodo de instalar alguns códigos de simulação. Eles são semelhantes em propósito às máquinas virtuais, mas muito mais leves e portáteis. Eles aumentam drasticamente a compartilhabilidade e a reprodutibilidade dos pacotes de software. Nesse método, o gerenciador de workflow e as ferramentas individuais rodam em contêineres^{Docker 12} , aumentando a compatibilidade com diferentes sistemas operacionais, desde que o usuário possa rodar contêineres.

Este protocolo é destinado a pesquisadores especialistas em domínio, por exemplo, engenheiros de neutrônica de fusão, analistas de dinâmica dos fluidos computacionais ou profissionais de elementos finitos, que são fluentes nas ferramentas de simulação de sua própria área, mas que não usaram anteriormente um gerenciador de fluxo de trabalho ou implantação baseada em contêineres. Pressupõe-se familiaridade com um único código de simulação e operação básica na linha de comando; familiaridade com Galaxy ou o Omniverso não é. Leitores iniciantes em conteinerização devem consultar a documentação oficial do Docker (https://docs.docker.com/) ou o treinamento introdutório disponível em: https://uomresearchit.github.io/docker-introduction/ antes de seguir a Seção 1; Os comandos básicos necessários para executar o software estão todos contidos no protocolo.

O restante deste relatório abordará a configuração e o uso do sistema implantável localmente. Depois, seguirá etapas para desenvolver novas ferramentas para o sistema e um método para vincular outros pacotes externos ao motor de fluxo de trabalho, como uma plataforma de metaverso. Ao longo do relatório, uma simulação de neutrônica usando o OpenMC¹³ serve como estudo de caso. O OpenMC foi selecionado porque demonstra o pipeline completo de CAD-para-simulação-para-visualização de saída que motiva a arquitetura do fluxo de trabalho. Um arquivo de geometria e um arquivo de configuração servem como entradas estruturadas; a simulação de transporte de nêutrons de Monte Carlo produz uma métrica escalar (a razão de reprodução de trítio, TBR) que pode ser comparada a uma faixa conhecida de valores, e um conjunto de dados espacialmente resolvido de trilha de nêutrons que pode ser processado e apresentado em um formato visualizável para a renderização 3D na aplicação do metaverso.

Protocolo

NOTA: Uma visão geral da configuração local do motor de fluxo de trabalho, construção, lançamento do fluxo de trabalho e resultados de visualização é mostrada nas Figuras 1, Figura 2, Figura 3, Figura 4, Figura 5, Figura 6, Figura 7 e Figura 8. Os arquivos de repositório necessários para executar o protocolo são fornecidos no Arquivo Suplementar 1.

1. Configuração

1. Requisitos
   NOTA: Este método foi testado na versão mais recente de Suporte a Longo Prazo (LTS) do Ubuntu, 22.04.1 LTS. Outras versões do Ubuntu e outras distribuições podem funcionar, mas não foram testadas aqui. Também funciona em sistemas Windows, utilizando o Windows Subsystem for Linux (WSL) como backend do Docker.
   1. Usuários Windows: Baixem o WSL e configurem-no, pois é um requisito para o Docker.
   2. Baixe o Docker e depois verifique executando:
      `Docker Administrado Hello-World'
      que deve mostrar uma mensagem de boas-vindas.
   3. Baixe o launcher NVIDIA Omniverse e um dos aplicativos Omniverse pelo launcher.
      NOTA: A renderização em tempo real com ray tracing do NVIDIA Omniverse requer uma GPU classe RTX. Usuários sem esse hardware ainda podem executar o fluxo de trabalho completo através da Seção 2 e inspecionar as saídas intermediárias .vtk / .vtp no ParaView (veja Discussão). Esses usuários podem pular a Seção 3, pois esta se aplica apenas à plataforma do metaverso; Os métodos usados para integrar o motor de fluxo de trabalho aqui podem ser úteis ao se conectar a outras plataformas do metaverso.
      Esse protocolo usa o aplicativo Omniverse Code, mas os outros aplicativos Omniverse devem ser amplamente semelhantes. Embora não seja essencial, o ParaView pode ser usado para visualizar alguns dos arquivos intermediários produzidos pelas ferramentas deste protocolo.
2. Repositório
   1. Clone o repositório que contém todos os arquivos e scripts necessários para a instância do motor de fluxo de trabalho local e as ferramentas descritas neste artigo com:
      'Vai https://github.com/williamjsmith15/galaxy-omniverse-example.git clone'
   2. Adicione um e-mail de administrador à lista de usuários administradores.
      NOTA: Isso concede os privilégios de administrador necessários para alguns recursos do motor de workflow e pode ser encontrado na seção admin_users no arquivo galaxy-config/galaxy.yml (veja https://github.com/williamjsmith15/galaxy-omniverse-example/blob/master/galaxy-config/galaxy.yml).
   3. Renomeie o arquivo default.json.template para default.json. Este arquivo está localizado em omni_exts/omni.galaxy.example/omni/galaxy/example/default.json.template.
      NOTA: Isso permitirá que seja lido pela extensão da plataforma metaverso e que configurações pessoais sejam adicionadas e persistidas entre os carregamentos — mais mudanças serão feitas após a configuração da instância galaxy.
3. Lançamento do Servidor do Motor de Fluxo de Trabalho Local
   1. Inicie a instância do motor de workflow executando o arquivo start-galaxy.sh no nível superior do repositório:
      './start-galaxy.sh'
      Se o arquivo não rodar aqui, pode ser necessário se tornar executável se as permissões mudaram no clone do repositório. Isso pode ser feito executando:
      'chmod a+x start-galaxy.sh'
      NOTA: Usuários do Windows devem fazer isso pelo terminal WSL. Isso baixará os arquivos relevantes e iniciará a instância do motor de workflow, que pode ser visualizada em http://localhost:8080 em qualquer navegador rodando na mesma máquina. Isso deve mostrar a página mostrada na Figura 1; Se não, espere e atualize — a instância do motor de workflow pode demorar para abrir (especialmente na primeira vez).
      1. Geralmente, para ver as mudanças feitas no repositório na instância do motor de workflow, execute './restart-galaxy.sh' ou './stop-galaxy.sh', e então inicie o script novamente.
4. Configuração da plataforma do Metaverso
   1. Abra o app após baixar o launcher e o app (neste exemplo, Omniverse Code).
   2. No canto superior esquerdo da janela, clique na aba Extensões (em outros apps, isso estará em Janela | Extensões).
   3. Na janela de extensões , clique no botão cinza de configurações ; Ele vai abrir uma janela com alguns diretórios já preenchidos. Adicione outro que aponte para a pasta omni_exts clicando no botão verde plus e adicione um caminho que terá o formato: '/exemplo-galaxy-omniverse/omni_exts'; veja a Figura 2 para mais detalhes.
   4. Procure por uma nova entrada chamada 'EXEMPLO DE OMNI GALAXY' na coluna da esquerda, abaixo da aba TERCEIROS . Mude o controle deslizante dessa extensão para ativado e espere a janela de extensão aparecer.
   5. Selecione a caixa de seleção de carregamento automático para carregar a extensão automaticamente toda vez que o app for iniciado.
      NOTA: As alterações feitas nos arquivos de extensão devem ser automaticamente mantidas quando o arquivo for salvo, pois o Omniverse permite recarregar as extensões a quente
5. Criação de conta no motor de fluxo de trabalho e link para o Metaverso
   1. Na instância do motor de fluxo de trabalho, crie uma conta clicando nos botões Logar ou Registrar na barra superior, depois em Cadastrar Aqui, e então preencha os dados usando o endereço de e-mail adicionado na Etapa 1.2.2 para criar uma conta com acesso de administrador.
   2. Gerar uma chave de API para permitir que a API se comunique com o motor de workflow. Vá para o menu suspenso do Usuário na barra superior | Preferências | Gerencie a chave da API. Crie uma chave e copie ela.
   3. Depois que a chave for gerada, adicione-a ao arquivo default.json criado no Passo 1.2.3, sob o campo 'galaxy_api_key' nas aspas vazias.
      ATENÇÃO: Este arquivo agora conterá uma chave de API. Essa chave API pode ser usada para executar trabalhos e acessar dados na conta associada. Isso não deve ser um problema em uma implantação local onde não há domínio público ou endereço IP; Esse arquivo ainda deve ser tratado como secreto e, portanto, não ser compartilhado ou comprometido em um repositório público (o arquivo é listado por padrão no .gitignore para combater isso).
   4. Reinicie o aplicativo da plataforma metaverso para atualizar as alterações feitas no arquivo padrão.
      NOTA: A chave API também pode ser adicionada diretamente à janela de extensão no menu suspenso das configurações do servidor, embora isso não persista entre as sessões.

2. Executar tarefas no Motor de Fluxo de Trabalho

1. Ferramentas individuais
   NOTA: Ferramentas únicas permitem que etapas individuais de processamento ou simulação sejam executadas e inspecionadas isoladamente, o que é útil para verificar se as entradas estão corretamente formatadas e se a ferramenta está funcionando como esperado antes de incorporá-las ao fluxo de trabalho. Os arquivos de teste referenciados abaixo, dagmc.h5m (a geometria CAD DAGMC) e openmc_config.json (a configuração de simulação), estão no diretório test_files do repositório clonado.
   1. Faça o upload dos arquivos de entrada necessários clicando em Upload Data na coluna da esquerda e selecione Escolher arquivos locais ou arraste e solte de um explorador de arquivos para essa janela. Faça upload do dagmc.h5m (arquivo CAD) e do openmc_config.json (arquivo de configuração), e então clique no botão Start para enviar para o histórico atual. Ambos os arquivos aparecerão em verde no painel de Histórico à direita quando o upload for concluído.
   2. Selecione o menu suspenso Ferramentas Complexas na coluna esquerda da página de destino e depois a ferramenta OpenMC Neutrtronics Simulation .
   3. Agora, na página específica da ferramenta, selecione as entradas dos arquivos que foram enviados no Passo 2.1.1 e selecione o arquivo CAD como o conjunto de dados dagmc.h5m e o arquivo de configuração como o conjunto de dados openmc_config.json .
   4. Clique no botão Executar . Dois novos arquivos (TBR e Faixas) aparecerão no painel de Histórico à direita da tela. Elas ficam laranjas ao rodar e verdes quando completas e bem-sucedidas, vermelhas indicam uma falha na ferramenta. Veja a Seção 4 para as etapas de depuração.
   5. O valor TBR (razão de reprodução de trítio) pode ser visualizado para verificar se o caso de teste foi executado com sucesso. Clique na saída da TBR para expandir, depois no ícone do gráfico e então no editor. Isso gera o resultado da TBR, que deve ser em torno de 0,76 (este é um método estatístico, e a configuração aqui usa um tamanho de amostra pequeno para a velocidade da simulação, então os resultados variarão).
      NOTA: O valor TBR é estocástico; O valor de 0,76 pode variar em ±0,01 e isso reflete uma contagem deliberadamente pequena de partículas (5 lotes de 1.000 partículas) escolhida para fluxos de trabalho rápidos de exemplo. Para reduzir a faixa de valores, aumente o número de lotes e partículas no campo de configurações no arquivo openmc_config.json antes de executar novamente. Como uma diretriz para uma geometria simples como o caso apresentado aqui, 50 lotes de 10.000 partículas devem reduzir a dispersão dos valores de TBR em execuções subsequentes, ao custo de um tempo de execução mais longo.
   6. Outras ferramentas podem ser executadas na saída Tracks do fluxo de trabalho para pós-processar os resultados. Execute a ferramenta Tracks h5 para vtp na saída Tracks e depois a ferramenta CAD h5m para vtk no arquivo de entrada dagmc.h5m . Ambos geram uma única saída, tracks_0.vtp e dagmc.vtk, que os converte em um formato mais facilmente visualizável.
   7. As saídas produzidas na etapa anterior podem ser baixadas da instância (clicando na saída e depois no ícone de salvamento) e depois podem ser visualizadas no ParaView¹⁴ para ver as trilhas simuladas de nêutrons.
   8. Para visualizar os resultados no ParaView, importe as saídas baixadas do tracks_0.vtp e dagmc.vtk . Esses aparecerão no lado esquerdo da janela. Clique no ícone Olho ao lado dos arquivos importados, ou no botão Aplicar abaixo na janela de propriedades para visualizar a saída. Isso deve ser semelhante ao visto na Figura 7.
2. Fluxos de trabalho
   NOTA: Um fluxo de trabalho codifica um pipeline completo de processamento como um grafo direcionado de ferramentas com entradas e saídas declaradas. Uma vez definido, o mesmo fluxo de trabalho pode ser executado novamente contra qualquer conjunto de arquivos de entrada sem precisar reconfigurar manualmente cada ferramenta, e todo o histórico de execução e metadados de proveniência são capturados automaticamente.
   1. Clique em Fluxo de Trabalho na barra de navegação superior e depois em Criar no canto superior direito. Digite um nome e uma descrição para o fluxo de trabalho (qualquer coisa serve), depois clique em Criar novamente.
   2. Adicione três ferramentas ao fluxo de trabalho, expanda as seções relevantes no menu Ferramentas e adicione as ferramentas usadas na seção 2.1: Simulação de Neutrônica OpenMC, CAD h5m para vtk e Tracks h5 para vtp.
   3. Defina o fluxo de dados entre as ferramentas. Arraste as ferramentas pelo espaço de trabalho clicando e arrastando a barra superior azul escura de cada uma delas. Conecte a saída Tracks (h5) da ferramenta de simulação de neutrônica à entrada tracks.h5 da ferramenta h5 para vtp. Faça isso clicando e arrastando da seta na saída até a seta na entrada.
   4. Defina os conjuntos de dados de entrada em nível de fluxo de trabalho. Na seção de Entradas das ferramentas, clique duas vezes em Conjunto de Dados de Entrada para criar dois nós de entrada. Renomeie um para o arquivo de configuração e o outro para a entrada CAD clicando no passo e depois mudando o campo Etiqueta no menu de propriedades da direita.
   5. Vincule o arquivo de configuração e o arquivo CAD às entradas da ferramenta de simulação neutrônica, e o arquivo CAD à ferramenta h5m para vtk, seguindo o padrão da Figura 3.
   6. Salve o fluxo de trabalho usando o ícone de salvar no canto superior direito.
   7. Para executar o fluxo de trabalho, clique na aba Workflow na barra superior como antes, depois clique no ícone de play no fluxo de trabalho a ser executado. Depois, selecione as entradas como no Passo 2.1.2, igual ao rodar uma ferramenta, e clique em Executar Fluxo de Trabalho.
   8. Espere o fluxo de trabalho rodar, e então as saídas podem ser comparadas aos passos 2.1.5 e 2.1.8; Esses devem ser muito semelhantes (novamente, observe a variação estatística desses passos). O fluxo de trabalho rodou com sucesso quando todas as saídas no Histórico ficaram verdes. Devem haver (junto com os conjuntos de dados de entrada) quatro conjuntos de dados presentes aqui: TBR, Tracks, dagmc.vtk e tracks_0.vtp.
   9. Como o fluxo de trabalho foi executado, alguns usuários podem querer ver a proveniência e os metadados capturados da invocação (execução) do fluxo de trabalho. Isso pode ser alcançado navegando até Usuário na barra superior | Invocações de Fluxo de Trabalho. Isso resulta na lista de todos os fluxos de trabalho executados pelo usuário, clicando na seta para baixo no fluxo de trabalho de interesse e, em seguida, pode baixar o arquivo JSON de metadados clicando no botão Download BioCompute Object . Isso contém a proveniência das ferramentas/fluxos de trabalho executados, entradas usadas, etc.
      NOTA: O motor de fluxo de trabalho também registra um histórico completo de execução para cada execução de workflow, incluindo checksums de arquivos de entrada, versões de ferramentas e valores de parâmetros. Para baixar o registro de procedência de uma execução, abra o painel Histórico , clique no menu (seta para baixo) no canto superior direito e selecione Exportar Histórico para Arquivo. O arquivo exportado contém todos os conjuntos de dados e um registro legível por máquina das etapas que os produziram.
      O salvamento de proveniência ou históricos gerados pelo motor de fluxo de trabalho pode ser automatizado via API discutida na Seção 5.1; no entanto, não será detalhado neste protocolo.
3. Fluxo de trabalho mais complexo
   NOTA: Este fluxo de trabalho estende a Seção 2.2 adicionando etapas de pós-processamento que produzem arquivos de Descrição Universal de Cena (USD) necessários para visualização na plataforma do metaverso. Como nenhuma ferramenta única converte diretamente do DAGMC (.h5m) ou VTK (vtp) para USD, o pipeline roteia os dados por meio de duas cadeias de conversão em múltiplas etapas: a geometria CAD segue um pipeline H5M, STL, OBJ, USD, e as trilhas de nêutrons seguem H5, VTP, OBJ, USD.
   1. Siga os passos para configurar um fluxo de trabalho, conforme mostrado na seção 2.2, seguindo o fluxo de trabalho mostrado na Figura 4.
   2. Defina as duas entradas em nível de fluxo de trabalho como no Passo 2.2.4, nomeando-as CAD DAGMC e Arquivo de Configuração.
   3. Adicione a ferramenta OpenMC Neutronics Simulation e conecte as entradas CAD DAGMC e Config File às suas entradas correspondentes, conforme na Etapa 2.2.3.
   4. Crie a cadeia de conversão de neutrônica. Adicione as Tracks h5 ao vtp, vtp ao obj e obj ao USD e então conecte as saídas de cada uma às entradas da próxima, seguindo o layout no ramo inferior da Figura 4.
   5. Crie a cadeia de conversão CAD. Adicione as ferramentas h5m ao STL, STL ao OBJ e OBJ ao USD, e então conecte novamente as saídas de cada uma às entradas da próxima, seguindo o layout no ramo superior da Figura 4.
   6. Salve o fluxo de trabalho, que agora está pronto para uso na plataforma do metaverso via extensão na Seção 3.
      NOTA: Essas etapas adicionais mostram aos usuários como fluxos de trabalho e ferramentas podem ser compartilhados, possibilitando reprodutibilidade e acessibilidade aos dados e métodos usados para gerar resultados.
   7. Exporte o fluxo de trabalho como um arquivo portátil navegando até o Fluxo de Trabalho na barra superior, clicando no menu (seta para baixo) e selecionando Baixar. O gerenciador de workflow salva um arquivo JSON .ga , que pode ser compartilhado e usado por qualquer pessoa com as mesmas ferramentas na instância do motor de workflow. Isso pode ser importado via Workflow na barra superior | Importar.
   8. Compartilhe ferramentas comprometendo a pasta galaxy-tools/ do repositório clonado em um host público de controle de versão. Peça aos colaboradores que clonem isso para ter acesso a todas as ferramentas conteinerizadas, executando-as da mesma forma que no dispositivo local do publisher.
      NOTA: Instâncias públicas de gerenciador de workflow podem ser configuradas, o que contorna o compartilhamento manual de workflow e arquivos de ferramentas entre implantações locais. Nesses casos, as ferramentas são acessíveis a todos os usuários, e fluxos de trabalho e históricos podem ser tornados públicos para todos os outros usuários. Isso está fora do escopo deste protocolo, mas mais informações podem ser encontradas na rede oficial de treinamento Galaxy sobre como obter uma implantação permanente: https://training.galaxyproject.org/training-material/topics/admin/tutorials/ansible-galaxy/tutorial.html ou a pilha docker compose fornecida no repositório pode ser implantada como está em um servidor e depois roteada por meio de um proxy ou meio semelhante para torná-la acessível publicamente.

3. Rodar um fluxo de trabalho a partir da plataforma do metaverso

1. Lançando o Fluxo de Trabalho
   1. Na janela da extensão da plataforma metaverso, clique em Obter Fluxos de Trabalho (anotação 2, Figura 5). Um menu suspenso será preenchido com todos os fluxos de trabalho disponíveis na conta do motor de fluxo de trabalho associada à chave API armazenada em default.json. Se isso não for o caso, verifique se a chave API foi salva corretamente no arquivo JSON e reinicie o aplicativo da plataforma metaverso para garantir que ele retenha a chave.
   2. Selecione o Fluxo de Trabalho Complexo para a lista e então clique em Obter Entradas (anotação 4, Figura 5). Os campos de entrada definidos no fluxo de trabalho (Passo 2.3.2) aparecerão e devem ter o mesmo nome.
   3. Para cada entrada baseada em arquivo, clique em Select File e use o pop-up do explorador de arquivos para selecionar o arquivo local correspondente: dagmc.h5m para a entrada CAD DAGMC e openmc_config.json para a entrada do Arquivo de Configuração .
   4. Clique em Iniciar Fluxo de Trabalho (anotação 6, Figura 5). Uma mensagem de confirmação de lançamento será exibida na seção Informações (anotação 7). Após a conclusão do fluxo de trabalho, mensagens adicionais confirmarão que os arquivos de saída foram salvos e que a execução foi concluída.
      NOTA: O progresso do trabalho do fluxo de trabalho pode ser monitorado na interface web do motor de fluxo de trabalho em http://localhost:8080 navegando para Admin | Jobs. É necessário acesso de administrador (veja Passo 1.2.2).
2. Visualizando os resultados
   NOTA: Ao concluir cada execução do fluxo de trabalho, o sistema baixa automaticamente os arquivos de saída do motor de fluxo de trabalho para um diretório de saída local. O caminho de salvar é controlado pela tecla output_dir no arquivo default.json da extensão. Cada execução é armazenada em uma pasta com carimbo de data, para que as saídas possam ser distinguidas pela extensão. Se houver problemas de visualização na plataforma do metaverso, os arquivos podem ser acessados nessas pastas e visualizados manualmente para ver se o problema está no motor de workflow.
   1. Na plataforma do metaverso, expanda a seção Gerenciador de Arquivos (anotação 1, Figura 6) e clique em Atualizar (anotação 2). Isso recupera a lista das execuções de fluxo de trabalho concluídas salva no diretório local.
   2. No menu suspenso Pastas (anotação 3, Figura 6), selecione a pasta para a execução atual do fluxo de trabalho (confirme se essa é a única que está lá atualmente) e clique em Atualizar novamente para preencher o menu suspenso Arquivos com os resultados dessa execução.
   3. Selecione um arquivo no menu suspenso Arquivos (anotação 4, Figura 6; atualmente apenas arquivos .usd, .txt, .json e .out são suportados) e então clique em Puxar Arquivo (anotação 5). Arquivos baseados em texto são exibidos no painel de Informações , arquivos USD são adicionados à cena atual e devem ser visualizados na janela principal de visualização.
   4. Para alinhar a geometria importada com a convenção de coordenadas do Omniverse, abra o painel de Estágio à direita, selecione ambos os objetos de workflow importados e, no painel de Propriedades logo abaixo, defina Girar X para −90°. Isso corrige a incompatibilidade entre a convenção z-up usada pelas ferramentas de exportação em USD e a convenção y-up do Omniverse. Aplique essa rotação tanto ao CAD USD quanto ao arquivo USD das trilhas; o estado esperado da janela de visualização após o alinhamento é mostrado na Figura 8.
   5. Por fim, para obter mais contraste entre as peças, materiais podem ser atribuídos. Isso é feito abrindo a aba Materiais na parte inferior do app, selecionando um material e arrastando e soltando para a geometria na visualização do Palco , na coluna da direita. Faça isso para ambas as geometrias importadas para aumentar o contraste entre elas.

4. Adicionando novas ferramentas

NOTA: Esta seção descreve o processo do desenvolvedor para criar e implantar novas ferramentas de fluxo de trabalho. Ele requer acesso ao sistema de arquivos do repositório e acesso de administrador ao motor de fluxo de trabalho para depuração. Usuários que só precisam executar ferramentas e fluxos de trabalho existentes, ou criar fluxos de trabalho, não precisam seguir esta seção.

1. Processo geral
   1. Desenvolva e teste o script de simulação ou processamento independentemente do motor de fluxo de trabalho antes de envolvê-lo. O wrapper das ferramentas chama um script de trabalho existente, implementar nova lógica enquanto se desenvolve uma ferramenta não é recomendado.
   2. Prepare o ambiente de execução para o script criando uma imagem Docker que inclua todas as dependências de tempo de execução (bibliotecas, binários, arquivos de dados, etc.) exigidas pelo script.
      NOTA: Todas as ferramentas de exemplo neste protocolo usam contêineres Docker como ambiente de execução. Ambientes Conda também são suportados pelo motor de workflow, mas não são demonstrados aqui. Mais informações sobre o Docker podem ser encontradas na documentação oficial, ou um bom curso introdutório pode ser encontrado aqui: https://uomresearchit.github.io/docker-introduction/ .
   3. Crie um arquivo de definição de ferramenta XML que declare o ambiente de execução (Docker neste caso), o comando para invocar o script e as entradas, saídas e metadados das ferramentas para exibição na interface do motor de workflow.
   4. Depois que o wrapper for criado, coloque o XML e quaisquer scripts em uma nova pasta galaxy-tools// no repositório. Adicione uma nova entrada para a ferramenta em galaxy-tools/tool_conf.xml sob as tags apropriadas, apontando para o caminho relativo do arquivo XML recém-criado.
      NOTA: Certifique-se de que este nome de arquivo seja copiado exatamente, pois este é um erro comum ao tentar implantar novas ferramentas. Se a tool_conf.xml entrada contiver um caminho incorreto ou o arquivo XML apresentar um erro de sintaxe, a instância do motor de fluxo de trabalho falhará ao iniciar. Para inspecionar os logs do contêiner do fluxo de trabalho em busca de mensagens de erro, execute o seguinte a partir da raiz do repositório:
      'docker compor logs galáxia'
      Erros de análise sintática XML aparecem como linhas da ferramenta de carregamento ERROR do formulário : e normalmente identificam o nome do arquivo e o número da linha do problema.
   5. Reimplante o mecanismo de fluxo de trabalho para carregar a nova ferramenta executando o script de reinício a partir da raiz do repositório: ./restart-galaxy.sh.
   6. Confirme se a ferramenta foi registrada corretamente. Navegue até http://localhost:8080, localize a ferramenta no painel de Ferramentas e clique nela para garantir que todos os inputs apareçam como esperado. Se a ferramenta estiver ausente, siga a nota acima para depuração e, se ainda houver erros, verifique a sintaxe do próprio XML da ferramenta, pois isso também pode causar erros de implantação.
   7. Execute a nova ferramenta como antes, mas com entradas que já foram testadas anteriormente. As saídas devem ficar verdes no painel de História
   8. Se as ferramentas falharem, então, como administrador, clique na saída falhada (vermelha) e clique no ícone de Informações . Ele mostra uma página detalhada de saída e exibe os streams stdout e stderr. Essas informações podem ser ampliadas para obter mais informações sobre a depuração da ferramenta.
2. Ferramentas simples
   NOTA: As ferramentas 1–5 ilustram padrões de envolvimento progressivamente mais complexos. O arquivo XML e quaisquer scripts para cada ferramenta estão no subdiretório galaxy-tools/simple// correspondente do repositório. Implante e execute cada ferramenta seguindo os Passos 4.1.4–4.1.5 e a Seção 2.1.
   Ferramenta 1 – Executando um comando simples
   1. Olhe o arquivo galaxy-tools/simple/1/1.xml . O elemento de requisitos especifica um ambiente de execução Linux. O elemento de comando contém o comando eco para executar.
   2. Execute a Ferramenta 1 a partir da interface do motor de fluxo de trabalho sem necessidade de arquivos de entrada. Como também não há arquivos de saída definidos, como Administrador, navegue até a página Administrador, Empregos e depois clique no ícone de Informações para ver os fluxos stdout e stderr, que é o mesmo do Passo 4.1.8. O fluxo stdout deve conter apenas a string 'hello world' do comando no arquivo XML.
      Ferramenta 2 – Uso de entrada baseada em texto
   3. Olhe o arquivo galaxy-tools/simple/2/2.xml . Agora há uma entrada no campo de entrada, com um elemento param type ="text" e a seção de comando agora faz referência à variável de entrada pela tag de nome.
   4. Execute a Ferramenta 2 como antes; Desta vez, dê à ferramenta um input de corda. Isso pode ser qualquer coisa que o usuário desejar. Veja a saída como no Passo 4.2.2, e a saída do stdout deve ser a string fornecida pelo usuário na entrada da ferramenta.
      Ferramenta 3 – Usando uma entrada baseada em arquivos
   5. Novamente, olhe para o arquivo de ferramentas; Agora, em vez de uma entrada de string, o parâmetro de entrada usa uma tag type="data", que permite o uso de um arquivo. Isso é referenciado na seção de comandos como um caminho de arquivo, novamente usando o nome do parâmetro de entrada.
   6. Crie um arquivo .txt usando um editor de texto local, se não executar:
      'Eco "Hello World a partir de um arquivo" > test_files/input.txt'
      da pasta raiz do repositório para gerar a entrada de exemplo.
   7. Faça upload do arquivo .txt criado conforme o Passo 2.1.1 e então execute a Ferramenta 3 como antes, selecionando o arquivo .txt carregado como entrada. Novamente, veja o stdout da mesma forma, e o conteúdo do arquivo .txt deve ser exibido lá. Se usar o comando acima, a saída deve ser "hello world from a file".
      Ferramenta 4 – Gravando saída em um arquivo
   8. Examine galaxy-tools/simple/4/4.xml. Uma seção de saída agora declara um arquivo de saída nomeado que pode ser referenciado na seção de comandos .
   9. Execute a ferramenta como antes com a entrada .txt , mas agora, em vez de visualizar a saída como administrador, isso pode ser visto pelo usuário comum neste painel de Histórico , e em uma execução bem-sucedida, ele ficará verde e poderá ser baixado / visualizado no motor de workflow conforme detalhado nas seções anteriores.
      Ferramenta 5 – Rodando scripts nas ferramentas
   10. Examine galaxy-tools/simple/5/5.xml e o script em python correspondente galaxy-tools/simple/5/5.py. No XML, o comando faz referência ao script Python do diretório da ferramenta, e a seção de requisitos agora faz referência a uma imagem Python, pois Python é necessário para rodar o script.
   11. Implante e execute a ferramenta da mesma forma, e ela deve se comportar da mesma forma que a Ferramenta 4 (Passo 4.2.9), exceto que desta vez executa um script em vez do comando direto.
3. Exemplo de ferramenta complexa
   NOTA: Esta seção documenta o desenvolvimento da ferramenta de neutrônica como um exemplo prático do padrão descrito na Seção 4.1. Os arquivos relevantes estão em galaxy-tools/complex/openmc/. O mesmo padrão se generaliza para qualquer código de simulação ou processamento.
   1. Desenvolva o script de execução para a simulação. Para este exemplo, o script run galaxy-tools/complex/openmc/openmc_run.py analisa um arquivo de configuração (openmc_config.json), escreve o arquivo de configurações de neutrônica e executa a simulação. Teste o script diretamente da linha de comando antes de empacotá-lo em uma imagem Docker.
   2. Construa o ambiente de execução do Docker usando o Dockerfile em galaxy-tools/complex/openmc/Dockerfile. Isso amplia a imagem pública com alguns pacotes extras. Construa e marque localmente ou faça referência a partir de um registro de container.
   3. Crie o wrapper XML galaxy-tools/complex/openmc/openmc.xml, declarando a imagem Docker do Passo 4.3.2 na seção de requisitos . O comando para executar junto com os arquivos de entrada e saída (como no exemplo da Seção 4.2) também deve ser definido.
   4. Implante a ferramenta conforme nos Passos 4.1.4-4.1.7 e então use as entradas de teste usadas na Seção 2 para garantir que a ferramenta esteja funcionando corretamente.
      NOTA: As ferramentas restantes na instância (Tracks h5 para vtp, CAD h5m para vtk, h5m para stl, stl para obj, vtp para obj, obj para USD) são conversores de formato de arquivo que seguem o mesmo padrão de desenvolvimento. Seus arquivos XML estão no diretório galaxy-tools/complex / e podem servir como exemplos de referência adicionais.

5. Conectando fluxos de trabalho ao Metaverso

NOTA: Esta seção fornece material de referência para desenvolvedores que descreve a integração da API do motor de fluxo de trabalho e a arquitetura da extensão da plataforma metaverso. Usuários que só precisam executar fluxos de trabalho a partir da plataforma do metaverso devem seguir a Seção 3 e não precisam ler esta seção. Desenvolvedores que desejam conectar uma aplicação front-end diferente ao motor de workflow devem começar pela Seção 5.1.

1. API do Motor de Fluxo de Trabalho
   NOTA: A Galaxy expõe uma API RESTful. A biblioteca Python Bioblend fornece um wrapper de nível mais alto ao redor dessa API e é a base para todos os scripts auxiliares usados neste protocolo. O Bioblend é instalado automaticamente nos ambientes de execução Docker relevantes fornecidos no repositório.
   1. Importe o Bioblend e estabeleça uma conexão com o motor de workflow em execução instanciando um objeto GalaxyInstance com o endereço do servidor e a chave de API da Etapa 1.5.2. Em Python em um ambiente com Bioblend instalado:
      `de bioblend.galaxy importação GalaxyInstance
      gi = GalaxyInstance(url='http://localhost:8080', key=)'
      NOTA: Isso só funcionará para implantações locais; se o motor de workflow for implantado em uma máquina remota, substitua o localhost pelo endereço e porta da instância configurada.
   2. Use as funções auxiliares na galaxy-api/helper_functs.py para realizar operações comuns: listar fluxos de trabalho disponíveis (get_workflows), recuperar definições de entrada de workflow (get_inputs) e iniciar um fluxo de trabalho com arquivos de entrada especificados (launch_workflow). Consulte as docstrings inline nesse arquivo para assinaturas de funções e tipos de retorno esperados.
   3. Estenda o helper_functs.py com outras funções conforme exigido pela aplicação. A API de referência completa pode ser encontrada em https://bioblend.readthedocs.io.
2. Vinculando fluxos de trabalho ao metaverso
   NOTA: Esta seção descreve apenas a arquitetura da extensão da plataforma metaverso para que os desenvolvedores possam adaptá-la para diferentes fluxos de trabalho, tipos adicionais de arquivos ou plataformas alternativas de metaverso.
   1. Abra o ponto de entrada principal da extensão em omni_exts/omni.galaxy.example/. Essa extensão usa a extensão base¹⁵ do Omniverse como ponto de partida. Depois, adiciona toda a funcionalidade do arquivo API Python das funções auxiliares descrita no passo 5.1.2 e fornece uma interface gráfica para interagir com os fluxos de trabalho.
   2. Quando os fluxos de trabalho são lançados, os dados que eles produzem são automaticamente baixados do motor de fluxo de trabalho e armazenados localmente, permitindo que sejam visualizados na plataforma do metaverso. Isso também permite que os metadados gerados durante a execução do fluxo de trabalho sejam salvos e tornados acessíveis, fornecendo assim a proveniência dos dados de simulação.
   3. Essa implementação utiliza a biblioteca nativa omni.ui do Omniverse para construir a interface. A extensão principal está na pasta de extensões, e a implementação principal da interface está no arquivo omni_exts/omni.galaxy.example/omni/galaxy/example/window.py .

Resultados

Se as simulações forem executadas com as entradas fornecidas no repositório git, os seguintes resultados devem ser obtidos:

Após a conclusão bem-sucedida da Etapa 2.1.3, tanto os conjuntos de dados de leitura (TBR) quanto os conjuntos de dados de saída de Tracks aparecerão no painel de Histórico em verde, indicando uma execução bem-sucedida. Um valor representativo de TBR usando o arquivo de configuração forne...

Discussão

Existem alguns passos críticos dentro do protocolo. A maioria diz respeito à configuração inicial da instância do motor de workflow, como: adicionar o e-mail de administrador (passo do protocolo 1.2.2), pois isso é necessário para acesso de administrador aos painéis de ferramentas e tarefas; gerando corretamente a chave API para a extensão da plataforma metaverso (passo de protocolo 1.5.3) e colando isso corretamente no arquivo de valores padrão; E ao adicionar ferramentas, garantindo qu...

Materiais

```html

Lista de materiais utilizados neste artigo

Nome	Empresa	Número de catálogo	Comentários
Bioblend	Galaxy Project	v1.2+	Biblioteca Python fornecendo um wrapper de alto nível em torno da API REST do Galaxy. Isso é usado nos scripts auxiliares da extensão Omniverse para listar fluxos de trabalho, recuperar definições de entrada e iniciar tarefas. Instalado automaticamente nas imagens Docker relevantes; nenhuma instalação no host necessária.
Docker Containers	Docker	v24.0.5	Runtime de conteinerização usado para empacotar cada simulação e ferramenta de pós-processamento com todas as suas dependências, garantindo portabilidade e reprodutibilidade.
Galaxy	Galaxy Project	v22.05	Motor de workflow de código aberto usado para orquestrar os ferramentas de simulação e processamento encadeados e expor-los através de uma API REST.
Git	Git SCM	v2+	Necessário para clonar o repositório para acompanhar o protocolo
NVIDIA RTX GPU	NVIDIA	-	Necessário para renderização em tempo real por ray-traced no Omniverse (Seção 3). Usuários sem hardware RTX podem completar todas as etapas até a Seção 2 e usar o ParaView para visualização (ver Discussão).
Omniverse	NVIDIA	Code 2022.3.3	Plataforma 3D colaborativa da NVIDIA. Isso é usado como o front-end de visualização e interação para saídas de workflow via uma extensão Kit personalizada.
ParaView	Kitware	v5.11	Aplicação de visualização científica de código aberto usada como um fallback não-RTX para inspecionar saídas intermediárias .vtk/.vtp.
Protocol Repository	Custom	v1.0	Contém a configuração do Galaxy junto com todos os wrappers XML de ferramentas, scripts de execução, Dockerfiles, dados de teste e a extensão Omniverse. Clonado na Etapa 1.2.1. Arquivos-chave também são fornecidos como uploads suplementares diretos (ver I.2).
Python	Python	v3.10+	Runtime necessário para o script de execução do OpenMC e os scripts auxiliares da extensão Omniverse. Incluso nas imagens Docker relevantes ou com o download do Omniverse; nenhuma instalação separada no host é necessária.
The OpenMC Monte Carlo Code	OpenMC	v0.13.3	Código de transporte de partículas Monte Carlo de código aberto usado aqui para simulação de fusão de nêutrons. Isso fornece a razão de criação de trítio (TBR) e saídas de traço de nêutron.
Windows Subsystem for Linux (WSL)	Microsoft	v2	Necessário para executar o Docker em hosts Windows (instalar via `wsl --install` no PowerShell). Usuários de Linux e Mac não precisam disso.

```