Integracja zautomatyzowanych przepływów symulacji z wizualizacją 3D do wirtualnych eksperymentów w Metaverse

Podsumowanie

Przedstawiono uogólnioną, zgodną z zasadami FAIR metodę dla ekspertów dziedzinowych, którzy chcą zintegrować narzędzia symulacyjne i do przetwarzania danych w zautomatyzowane przepływy pracy dla wirtualnych eksperymentów 3D. Przykład neutroniki pokazuje, jak skonfigurować lokalną instancję Galaxy, integrując OpenMC i narzędzia do konwersji plików, uruchamiać przepływy pracy z Omniverse oraz wizualizacje skonwertowanych wyników 3D.

Streszczenie

W wielu eksperymentach wirtualnych stosowanych jest wiele pakietów oprogramowania z różnymi typami symulacji, narzędziami do przetwarzania wstępnego i końcowego oraz narzędziami do wizualizacji wyników eksperymentów—często w połączeniu wszystkich wymienionych. Typowa metoda integracji tych elementów jest ręczna, z niestandardowymi rozwiązaniami stworzonymi dla każdego obszaru zastosowania, która słabo skaluje się i utrudnia udostępnianie i powtarzalność.

Ten protokół demonstruje wdrożenie i użycie zlokalizowanego systemu przepływu pracy w kontenerze. Wykonując go, użytkownicy uruchomią lokalną instancję Galaxy za pomocą Dockera, stworzyją i uruchomią przepływ pracy symulacji neutroniki OpenMC, przepuszczą wyniki przez łańcuch narzędzi do konwersji formatów i załadują wyniki zarówno do ParaView, jak i do NVIDIA Omniverse w celu wizualizacji. Konteneryzowane wdrożenie promuje powtarzalność i przenośność na dowolnym komputerze spełniającym wymagania sprzętowe opisane w Sekcji 1.

Po uruchomieniu systemu przepływy pracy mogą być ponownie uruchomione dla nowych danych wejściowych bez konieczności ręcznej rekonfiguracji, dodatkowe kody symulacyjne mogą być skonfigurowane jako nowe narzędzia przy niewielkim wysiłku, a narzędzia mogą być używane w wielu przepływach pracy i obszarach zastosowania. Podejście wspiera zasady danych FAIR (znajdowanie, dostęp, interoperacyjność, ponowne użycie): historie uruchomienia rejestrują pełne metadane dotyczące proweniencji, przepływy pracy mogą być eksportowane jako przenośne pliki i mogą być udostępniane bezpośrednio między instancjami Galaxy, a narzędzia są pakowanie w kontenery kontrolowane wersjami, które mogą być publikowane w publicznym repozytorium. Skalowalność do wysokowydajnych obliczeń (HPC) lub zasobów chmurowych poprzez system Pulsar Galaxy jest naturalnym rozszerzeniem opisanej tutaj architektury.

Metoda jest demonstrowana poprzez przypadek studyjny z zakresu neutroniki fuzyjnej. OpenMC jest używany do symulacji transportu neutronów w geometrii komputerowego wspomagania projektowania (CAD) Direct Accelerated Geometry Monte Carlo (DAGMC), wytwarzając wynik w postaci współczynnika hodowli trytu (TBR) i zestaw danych śladów neutronów. Przepływy pracy symulacji są następnie połączone z platformą metawersum NVIDIA Omniverse w celu wywołania i wizualizacji.

Wprowadzenie

Przemysłowy metawers łączy świat cyfrowy i fizyczny w celu wsparcia projektowania, symulacji oraz współpracy przy 3D wizualizacji systemów inżynierskich. Zazwyczaj składałby się z wielu połączonych cyfrowych bliźniaków komponentów, aby uzyskać ogólny widok systemu. Duże organizacje takie jak Boeing, BMW, Amazon i wiele innych podejmują wiele podejść do tworzenia metawersów¹. Opracowano systemy umożliwiające wiele łańcuchów symulacji i narzędzi przetwarzania, które są obecnie używane. Jednakże, te przykłady są zwykle dedykowane do określonych obszarów zastosowania² lub są opcjami komercyjnymi^3,4 z pewnym ograniczeniem w zakresie własności systemów. Niektóre alternatywy open-source do budowy cyfrowych bliźniaków zostały wykorzystane do stworzenia niektórych systemów, takich jak Python Flask, z wbudowanymi możliwościami symulacji. Jednakże, są one skonfigurowane jako dedykowane fragmenty kodu do wykonywania określonych zadań dotyczących danego modelu⁵. W kontekście tego protokołu, platforma metawersowa (NVIDIA Omniverse) działa jako 3D front-end wizualizacji i interakcji z przepływem pracy: wyniki symulacji są wczytywane do współdzielonej sceny po zakończeniu przepływu pracy, a nowe uruchomienia mogą być uruchamiane z tego samego środowiska. Różni się to od żywych systemów cyfrowych bliźniaków, w których aktualne dane z czujników ciągle aktualizują model; metoda przedstawiona tutaj obsługuje wykonanie wsadowe przepływów pracy i eksplorację wyników po uruchomieniu. Jednakże, robi się to w taki sposób, że wspiera przyszłą pracę nad integracją więcej systemów do platformy metawersowej, aby umożliwić tworzenie cyfrowych bliźniaków z silnikami przepływów pracy jako komputacyjnym backendem.

Przepływy pracy można zdefiniować jako łańcuchy narzędzi oprogramowania, jasno określające przepływ danych między nimi. Pozwalają na owijanie istniejących kodów symulacji, skryptów przetwarzania i innych kroków w typowej potoce analizy, bez zmiany ich funkcji, ale zamiast tego umożliwiają konfigurowanie i przekonfigurowywanie ich z ustandaryzowanymi wejściami i wyjściami, które są niezależne od narzędzi. Przepływy pracy umożliwiają łatwe replikowanie wyników poprzez udostępnianie narzędzi, zapewniając również metadane i pochodzenie dotyczące wersji narzędzi, w jakiej kolejności i z jakimi wejściami zostały użyte. Narzędzia same w sobie mogą być wielokrotnie używane w wielu potokach symulacji, pozwalając badaczom wydać mniej czasu na konfigurowanie symulacji i więcej na projektowanie eksperymentów i analizowanie wyników. Systemy przepływów pracy są również skalowalne, z metodami połączenia z różnymi lokalnymi zasobami obliczeniowymi, chmurą i zasobami HPC, umożliwiając uruchamianie wielu dużych przepływów pracy na określonym sprzęcie w zautomatyzowany sposób⁶.

Typowy manualny podejście jest z natury wolne, podatne na błędy i trudne do odtworzenia, w którym badacz uruchamia każdą symulację lub narzędzie do przetwarzania sekwencyjnego ręcznie, przenosi pliki pośrednie między środowiskami i musi dokumentować indywidualne wejścia i wyjścia dla poszczególnych uruchomienia. W przeciwieństwie do tego, zarządca przepływów pracy formalizuje przepływ danych raz na zawsze i ponownie uruchamia go deterministycznie. To przynosi wiele korzyści względem manualnych potoków: ten sam przepływ może być wykonany identycznie na różnych wejściach, wspierając badania parametryczne bez potrzeby specjalnego skryptowania; każde uruchomienie automatycznie rejestruje pełne metadane pochodzeniowe, rozwiązując problemy z powtarzalnością; i po tym, jak narzędzie zostanie zawinięte, jego koszt ponownego użycia w kolejnych przepływach spada prawie do zera, z wyjątkiem czasu obliczeniowego. Te korzyści zostały zmierzone dla bioinformatyki przez Wratten i wsp.⁷ oraz dla proteomiki/metabolomiki przez Perez-Riverol i Moreno⁸ oraz Verhoeven i wsp.⁹.

Historycznie, przepływy pracy były używane głównie w dziedzinie bioinformatyki^8,9 z dużym sukcesem z dużymi publicznymi instancjami takimi jak europejski serwer Galaxy^10,11, który do 2022 roku udostępniał ponad 50 tysięcy użytkowników, 2500 narzędzi, wykonał ponad 47 milionów zadań i 260 tysięcy uruchomienia przepływów pracy. Ten sam silnik przepływu pracy wspiera skalowanie na zasoby HPC i chmury poprzez rozproszony system wykonywania zadań Pulsar^6,11, z operacyjnymi wdrożeniami obejmującymi 13 punktów Pulsar w 10 krajach europejskich. Wśród wielu dostępnych zarządców przepływów pracy, w tym Snakemake, Nextflow, Toil i silniki zgodne z CWL, silnik przepływu pracy Galaxy¹¹ został wybrany z kilku powodów. Jednym z głównych powodów jest dojrzała interfejs użytkownika oparta na przeglądarce, która obniża barierę wejścia dla ekspertów dziedzinowych, którzy nie pracują głównie w linii polec

Protokół

UWAGA: Przegląd konfiguracji lokalnego silnika przepływu pracy, budowy przepływu pracy, uruchamiania przepływu pracy i wyników wizualizacji przedstawiono na Rysunek 1, Rysunek 2, Rysunek 3, Rysunek 4, Rysunek 5, Rysunek 6, Rysunek 7, i Rysunek 8. Pliki repozytorium wymagane do uruchomienia protokołu są dostępne w Dodatkowym pliku 1.

1. Konfiguracja

1. Wymagania
   UWAGA: Ta metoda została przetestowana na najnowszej wersji Long Term Support (LTS) Ubuntu, 22.04.1 LTS. Inne wersje Ubuntu i inne dystrybucje mogą działać, ale nie zostały tu przetestowane. Działa również w systemach Windows, korzystając z Windows Subsystem for Linux (WSL) jako backend Dockera.
   1. Użytkownicy Windows: Pobierz WSL i skonfiguruj go, ponieważ jest to wymóg dla Dockera.
   2. Pobierz Dockera, a następnie zweryfikuj, uruchomić:
      `docker run hello-world`
      który powinien wyświetlić wiadomość powitalną.
   3. Pobierz launchera NVIDIA Omniverse i jedną z aplikacji Omniverse za pośrednictwem launchera.
      UWAGA: Renderowanie w czasie rzeczywistym z promieniami w Omniverse wymaga GPU klasy RTX. Użytkownicy bez tego sprzętu mogą nadal uruchomić pełny przepływ pracy poprzez Sekcję 2 i przeglądać średnie pliki wyjściowe .vtk / .vtp w ParaView (zobacz Dyskusję). Ci użytkownicy mogą pominąć Sekcję 3, ponieważ dotyczy ona tylko platformy metaverse; metody używane do integracji silnika przepływu pracy tutaj mogą być przydatne przy podłączaniu do innych platform metaverse.
      Ten protokół używa aplikacji Omniverse Code, ale inne aplikacje Omniverse powinny być ogólnie podobne. Chociaż nie jest to konieczne, ParaView może być używany do wizualizacji niektórych plików pośrednich wyprodukowanych przez narzędzia w tym protokole.
2. Repozytorium
   1. Sklonuj repozytorium zawierające wszystkie pliki i skrypty potrzebne do lokalnej instancji silnika przepływu pracy i narzędzi opisanych w tym artykule za pomocą:
      `git clone https://github.com/williamjsmith15/galaxy-omniverse-example.git`
   2. Dodaj e-mail administratora do listy użytkowników administratorów.
      UWAGA: Daje to uprawnienia administratora potrzebne do niektórych funkcji silnika przepływu pracy i można je znaleźć w sekcji admin_users w pliku galaxy-config/galaxy.yml (zobacz https://github.com/williamjsmith15/galaxy-omniverse-example/blob/master/galaxy-config/galaxy.yml).
   3. Zmień nazwę pliku default.json.template na default.json. Ten plik znajduje się w omni_exts/omni.galaxy.example/omni/galaxy/example/default.json.template.
      UWAGA: Pozwoli to na jego odczytanie przez rozszerzenie platformy metaverse i na dodawanie i przechowywanie ustawień osobistych między ładowaniami - więcej zmian w tym pliku zostanie wprowadzonych po skonfigurowaniu instancji galaxy.
3. Uruchomienie lokalnego serwera silnika przepływu pracy
   1. Uruchom instancję silnika przepływu pracy, uruchomić plik start-galaxy.sh na najwyższym poziomie repozytorium:
      `./start-galaxy.sh`
      Jeśli plik nie zostanie uruchomiony tutaj, może być konieczne uczynienie go wykonywalnym, jeśli uprawnienia uległy zmianie w sklonowanym repozytorium. Można to zrobić, uruchomić:
      `chmod a+x start-galaxy.sh`
      UWAGA: Użytkownicy Windows muszą to zrobić za pośrednictwem terminala WSL. Spowoduje to pobranie odpowiednich plików i uruchomienie instancji silnika przepływu pracy, którą można zobaczyć pod adresem http://localhost:8080 w dowolnej przeglądarce uruchomionej na tej samej maszynie. Powinno wyświetlić się stronę przedstawioną na Rysunek 1; jeśli nie, poczekaj i odśwież - uruchomienie instancji silnika przepływu pracy może zająć trochę czasu (szczególnie przy pierwszym uruchomieniu).
      1. Zasadniczo, aby zobaczyć zmiany wprowadzone w repozytorium na instancji silnika przepływu pracy, uruchom `./restart-galaxy.sh` lub `./stop-galaxy.sh`, a następnie uruchom skrypt ponownie.
4. Konfiguracja platformy Metaverse
   1. Otwórz aplikację po pobraniu launchera i aplikacji (w tym przykładzie Omniverse Code).
   2. W górnym lewym rogu okna kliknij zakładkę Rozszerzenia (w innych aplikacjach będzie to pod Okno | Rozszerzenia).
   3. W oknie rozszerzeń kliknij szary przycisk ustawienia; pojawi się okno z kilkoma już wypełnionymi katalogami. Dodaj kolejny, który wskazuje na folder omni_exts, klikając zielony przycisk plus i dodając ścieżkę, która będzie miała format: ‘/galaxy-omniverse-example/omni_exts’; zobacz Rysunek 2 aby uzyskać więcej szczegółów.
   4. Poszukaj nowego w

Wyniki

Jeśli symulacje zostaną uruchomione z parametrami wejściowymi dostarczonymi w repozytorium git, powinny zostać uzyskane następujące wyniki:

Po pomyślnym zakończeniu Kroku 2.1.3 oba zestawy danych wyjściowych, TBR oraz Tracks , pojawią się w panelu History na kolor zielony, co wskazuje na pomyślne wykonanie procesu. Reprezentatywna wartość TBR przy użyciu dostarczonego pliku konfiguracyjnego (5 partii po 1000 cząstek) wynosi około 0,76, z różni...

Dyskusja

Istnieje kilka kluczowych kroków w protokole. Większość dotyczy początkowego ustawienia wystąpienia silnika przepływu pracy, takiego jak: dodanie adresu e-mail administratora (krok protokołu 1.2.2), ponieważ jest to wymagane dla dostępu administratora do paneli narzędzi i zadań; poprawne wygenerowanie klucza API dla rozszerzenia platformy metaverse (krok protokołu 1.5.3) i poprawne wklejenie go do pliku wartości domyślnych; oraz przy dodawaniu narzędzi, upewnienie się, że są one dodawane do pliku konfiguracji narzędzi (k...

Materiały

Lista materiałów użytych w tym artykule

Nazwa	Firma	Numer katalogowy	Komentarze
Bioblend	Galaxy Project	v1.2+	Biblioteka Python zapewniająca wysokiego poziomu wrapper wokół Galaxy REST API. Jest używana w skryptach pomocniczych rozszerzenia Omniverse do wyświetlania przepływów pracy, pobierania definicji wejściowych i uruchamiania zadań. Instalowany automatycznie w odpowiednich obrazach Dockera; nie wymaga instalacji na hoście.
Docker Containers	Docker	v24.0.5	Środowisko uruchomieniowe konteneryzacji używane do pakowania każdego narzędzia symulacji i przetwarzania post-processing wraz ze wszystkimi jego zależnościami, zapewniając przenośność i powtarzalność.
Galaxy	Galaxy Project	v22.05	Otwarty silnik przepływu pracy używany do orkiestracji łańcuchowych narzędzi symulacji i przetwarzania oraz do udostępniania ich przez interfejs API REST.
Git	Git SCM	v2+	Wymagane do klonowania repozytorium, aby móc śledzić protokół
NVIDIA RTX GPU	NVIDIA	-	Wymagany do renderowania w czasie rzeczywistym z użyciem promieniowania w Omniverse (Sekcja 3). Użytkownicy bez sprzętu RTX mogą wykonać wszystkie kroki do sekcji 2 i użyć ParaView do wizualizacji (patrz Dyskusja).
Omniverse	NVIDIA	Code 2022.3.3	Współpracująca platforma 3D firmy NVIDIA. Jest używana jako front-end wizualizacji i interakcji dla wyjść przepływu pracy za pośrednictwem niestandardowego rozszerzenia Kit.
ParaView	Kitware	v5.11	Otwarta aplikacja do wizualizacji naukowej używana jako alternatywa dla nie-RTX do inspekcji pośrednich wyjść.vtk/.vtp.
Protocol Repository	Custom	v1.0	Zawiera konfigurację Galaxy wraz ze wszystkimi plikami XML narzędzi, skryptami uruchomieniowymi, plikami Dockerfiles, danymi testowymi i rozszerzeniem Omniverse. Klonowana w kroku 1.2.1. Kluczowe pliki są również dostarczane jako bezpośrednie dodatkowe uploads (patrz I.2).
Python	Python	v3.10+	Środowisko uruchomieniowe wymagane dla skryptu uruchomieniowego OpenMC i skryptów pomocniczych rozszerzenia Omniverse. Dołączone w odpowiednich obrazach Dockera lub w pobraniu Omniverse; nie wymaga osobnej instalacji na hoście.
The OpenMC Monte Carlo Code	OpenMC	v0.13.3	Otwarty kod Monte Carlo do transportu cząstek używany tutaj do symulacji neutroniki fuzji. Dostarcza wskaźnik rozmnażania trytu (TBR) i wyjścia śladów neutronów.
Windows Subsystem for Linux (WSL)	Microsoft	v2	Wymagany do uruchomienia Dockera na hostach Windows (instalacja za pomocą `wsl --install` w powershell). Użytkownicy Linuksa i Maca tego nie potrzebują.