メタバースにおける仮想実験のための自動シミュレーションワークフローと3D可視化の統合

サマリー

3D仮想実験の自動化ワークフローにシミュレーションおよびデータ処理ツールを統合しようとする分野専門家研究者向けに、一般的かつFAIR準拠の手法を提示します。ニュートロニクスの例としては、ローカルのGalaxyインスタンスの設定、OpenMCやファイル変換ツールのラップ、Omniverseからのワークフローの起動、変換された3D出力の可視化などが示されています。

要約

多くの仮想実験では、複数のソフトウェアパッケージが多様なシミュレーションタイプ、前処理および後処理ツール、実験結果を可視化するツールが使用されており、多くの場合、これらすべてが組み合わさっています。これらを統合する典型的な方法は手動で、各アプリケーション分野ごとにカスタムソリューションを作成するため、スケールが悪く、共有や再現性を妨げます。

このプロトコルは、ローカルコンテナ化されたワークフローシステムの展開と利用を示しています。その後、ユーザーはDockerを使ってローカルのGalaxyインスタンスを起動し、OpenMCニュートロニクスシミュレーションワークフローを作成・実行し、出力をフォーマット変換ツールの連鎖に通し、結果をParaViewとNVIDIA Omniverseの両方に読み込んで可視化します。コンテナ化展開は、セクション1で説明するハードウェア要件を満たす任意のマシンでの再現性と移植性を促進します。

システムが稼働すると、ワークフローは手動の再構成なしに新しい入力に対して再実行でき、追加のシミュレーションコードを控えめな労力で新しいツールとしてラップでき、複数のワークフローやアプリケーション分野でツールを活用できます。このアプローチは、検索可能でアクセス可能、相互運用可能、再利用可能(FAIR)のデータ原則をサポートしています。すなわち、実行履歴は完全な出所メタデータを取得し、ワークフローはポータブルファイルとしてエクスポート可能でGalaxyインスタンス間で直接共有可能で、ツールはバージョン管理されたコンテナにパッケージされて公開リポジトリに公開されます。GalaxyのPulsarシステムを通じて高性能計算(HPC)やクラウドリソースへのスケーラビリティは、ここで説明したアーキテクチャの自然な拡張です。

この方法は核融合中性子のケーススタディを通じて実証されています。OpenMCは、直接加速幾何学モンテカルロ(DAGMC)コンピュータ支援設計(CAD)形状学における中性子輸送のシミュレーションに用いられ、トリチウム繁殖比(TBR)結果と中性子トラックデータセットを生成します。シミュレーションワークフローは、呼び出しと可視化のためのメタバースプラットフォームとしてNVIDIA Omniverseに接続されます。

概要

産業用メタバースは、デジタル世界と物理世界を組み合わせ、設計、シミュレーション、そしてエンジニアリングシステムの協働的な3D可視化を支援します。通常、多数の相互接続されたデジタルツインのコンポーネントで構成され、全体のシステムビューを提供します。ボーイング、BMW、アマゾンなどの大手組織は、メタバース1を作るために複数のアプローチを取^{っています。}複数のシミュレーションおよび処理ツールの連鎖を可能にするシステムが開発され、使用されています。しかし、これらの例は通常、アプリケーションエリア²向けに特注されたか、商業オプション^3,4で、一部は独自システムにロックインされています。デジタルツイン構築のためのオープンソースの代替手段として、Python Flaskのようにシミュレーション機能を備えたシステムの開発に使われています。それでも、これらは特定のモデル⁵に関連する特定のタスクを実行するための専用コードとして構成されています。このプロトコルの文脈では、メタバースプラットフォーム(NVIDIA Omniverse)は3D可視化およびワークフローインタラクションのフロントエンドとして機能します。ワークフロー実行完了後、シミュレーション出力は共有シーンに読み込まれ、同じ環境内から新しい実行をトリガーできます。これはリアルタイムのセンサーフィードがモデルを継続的に更新するライブデジタルツインシステムとは異なります。ここで示す手法は、バッチワークフローの実行と実行後の検索結果をサポートします。しかし、これは今後、より多くのシステムをメタバースプラットフォームに統合し、ワークフローエンジンを計算バックエンドにしたデジタルツインの作成を可能にするための取り組みを支援する形で行われています。

ワークフローは、それらの間のデータフローを明示的に指定したソフトウェアツールの連鎖として定義できます。既存のシミュレーションコード、処理スクリプト、その他のステップを典型的な解析パイプライン内でラップし、機能を変更することなく、ツールに依存しない標準化された入力・出力で設定・再構成を可能にします。ワークフローはツールの共有を通じて結果の容易な複製を可能にし、どのバージョンのツールがどの順序で、どの入力で使われたかのメタデータや出所も提供します。ツール自体は多くのシミュレーションパイプラインで再利用できるため、研究者はシミュレーションの準備にかかる時間を減らし、実験の設計や結果の探求により多くの時間を割くことができます。ワークフローシステムはスケーラブルで、異なるローカルの計算、クラウド、HPCリソースに接続する方法があり、多くの大規模ワークフローを特定のハードウェア上で自動化して実行すること^{を可能にします。}

典型的な手動のアプローチは本質的に遅く、エラーが多く再現が困難であり、研究者が各シミュレーションや後処理ツールを手作業で操作し、中間ファイルを環境間で移動させ、個々の実行の入力と出力を記録しなければなりません。これに対し、ワークフローマネージャーはデータフローを一度形式化し、決定論的に再実行します。これは手動パイプラインに比べて多くの利点をもたらします。同じワークフローを異なる入力で同一に実行でき、カスタムスクリプトなしでパラメータ調査をサポートできること。すべての実行は自動的に完全なプロヴィナンスメタデータを取得し、再現性のギャップを補います。ツールがラップされると、その後のワークフローでの再利用コストは計算時間を除いてほぼゼロに減少します。これらの利点は、Wrattenら7によってバイオインフォマティクス、Perez-Riverolと^Moreno8、Verhoevenら9によってプロテオミクス/メタボロミクス分野で定量化^{されています。}

歴史的に、ワークフローは主にバイオインフォマティクス分野で使われてきました。^8,9はヨーロッパのGalaxy Server^10,11のような大規模な公開インスタンスで大きな成功を収めており、2022年までに5万人以上のユーザー、2,500のツール、4,700万以上のジョブ、26万回のワークフロー実行を行っていました。同じワークフローエンジンスタックは、Pulsar分散ジョブ^{実行システム6,11}を通じてHPCおよびクラウドリソースへのスケーリングをサポートし、10か国にわたる13のPulsarエンドポイントにまたがる運用展開が行われています。Snakemake、Nextflow、Toil、CWL互換エンジンなど多くのワークフローマネージャーの中で、いくつかの理由でGalaxy ワークフローエンジン¹¹が選ばれました。主な理由の一つは、コマンドラインを主に扱わないドメイン専門家の参入障壁を下げる成熟したブラウザベースのインターフェースです。完全な表現状態転送(REST)アプリケーションプログラミングインターフェース(API)を公開しており(本作業ではメタバースフロントエンドへのブリッジとして使用)、その歴史とジョブズモデルは、非専門の協力者でも簡単に理解できる形で出自を捉えています。また、前述のPulsarシステムによる透過的なHPCオフロードもサポートしています(ただし、本論文のプロトコルセクションではこの点については触れていません)。しかし、本論文で説明されているアプローチは、原則としてワークフローエンジンに依存しないものであり、代替エンジンの上に同等の統合を構築することも可能です。この仕事の貢献はワークフローマネージャー自体ではなく、もともとバイオインフォマティクス向けに開発された汎用ワークフローマネージャーを他分野(ここでは融合ニュートロニクスの具体例として)に移植し、産業用メタバースプラットフォーム(NVIDIA Omniverse)との統合を、完全にコンテナ化されローカル展開可能なスタック内に統合し、3D仮想実験に応用したことです。

最後に、コンテナ化はコードをオペレーティングシステムと実行に必要なすべての依存関係にパッケージ化することで、多くのソフトウェアの共有を可能にします。これらの環境は依存関係の欠落やシミュレーションコードのインストールの手間を回避します。目的は仮想マシンに似ていますが、はるかに軽量で携帯性が高いです。これらはソフトウェアパッケージの共有性と再現性を大幅に高めます。この方法では、ワークフローマネージャーや個別ツールがDocker¹² コンテナ上で動作し、ユーザーがコンテナを実行できる限り異なるオペレーティングシステムとの互換性が向上します。

このプロトコルは、融合中性子工学者、計算流体力学分析者、有限要素実務者など、自分の分野のシミュレーションツールに精通しているが、ワークフローマネージャーやコンテナベースのデプロイメントをこれまで使ったことがない分野の専門家を対象としています。単一のシミュレーションコードと基本的なコマンドライン操作に慣れていることが前提です。ギャラクシーやオムニバースへの親しみは違います。コンテナ化に初めて触れる読者は、公式のDockerドキュメント(https://docs.docker.com/)または入門トレーニングを参照してください:セクション1に従う前に https://uomresearchit.github.io/docker-introduction/ ;ソフトウェアを実行するために必要な基本的なコマンドはすべてプロトコルに含まれています。

本レポートの残りの部分では、ローカル展開可能なシステムのセットアップと利用について扱います。その後、システム用の新しいツール開発や、メタバースプラットフォームなど他の外部パッケージをワークフローエンジンにリンクする方法を案内します。報告書全体を通じて、OpenMC¹³ を用いた中性子シミュレーションがケーススタディとして用いられています。OpenMCが選ばれたのは、CADからシミュレーション、出力、可視化までのワークフローアーキテクチャを推進する完全なパイプラインを示しているからです。ジオメトリファイルと設定ファイルが構造化入力として機能します。モンテカルロ中性子輸送シミュレーションは、既知の範囲の値と比較可能なスカラー指標(トリチウム繁殖比、TBR)と、メタバースアプリケーションでの3Dレンダリング用に可視化可能な空間的に分解された中性子トラックデータセットを生成します。

プロトコル

注:ローカルワークフローエンジンの設定、ワークフロー構築、ワークフロー起動、可視化出力の概要は図1、図2、図3、図4、図5、図6、図7、図8に示されています。プロトコルを実行するために必要なリポジトリファイルは補足ファイル1に提供されています。

1. セットアップ

1. 要件
   注:この方法は最新の長期サポート(LTS)バージョンであるUbuntu 22.04.1 LTSでテストされています。他のUbuntuや他のディストリビューションのバージョンは動作するかもしれませんが、ここではテストされていません。また、Windowsシステムでも動作し、DockerのバックエンドとしてWindows Subsystem for Linux(WSL)を利用しています。
   1. Windowsユーザーの皆さん:WSLをダウンロードして設定してください。Dockerには必須です。
   2. Dockerをダウンロードして、以下を実行して検証します:
      `Docker run Hello-World'
      そこにウェルカムメッセージが表示されるはずです。
   3. ランチャーを通じてNVIDIA OmniverseランチャーとOmniverseアプリのいずれかをダウンロードしてください。
      注:NVIDIA OmniverseのリアルタイムレイトレースレンダリングにはRTXクラスのGPUが必要です。このハードウェアを持たないユーザーも、セクション2を通じて全ワークフローを実行し、ParaViewで中間の .vtk / .vtp 出力を確認できます(議論参照)。これらのユーザーはセクション3をスキップできます。セクション3はメタバースプラットフォームのみに限定されているためです。ここで使われているワークフローエンジンの統合方法は、他のメタバースプラットフォームに接続する場合に役立つかもしれません。
      このプロトコルはOmniverse Codeというアプリを使用していますが、他のOmniverseアプリも大まかに似ているはずです。必須ではありませんが、ParaViewはこのプロトコルのツールによって生成される中間ファイルの可視化に利用できます。
2. リポジトリ
   1. ローカルワークフローエンジンインスタンスに必要なすべてのファイルとスクリプトを収容したリポジトリをクローンし、本論文で説明したツールも以下の通りです:
      「クローン https://github.com/williamjsmith15/galaxy-omniverse-example.git ろ」
   2. 管理者のメールアドレスを管理者ユーザーリストに追加してください。
      注意:これにより、ワークフローエンジンの一部の機能に必要な管理者権限が得られ、galaxy-config/galaxy.ymlファイルの admin_users セクション(https://github.com/williamjsmith15/galaxy-omniverse-example/blob/master/galaxy-config/galaxy.yml 参照)で確認できます。
   3. default.json.templateファイルをdefault.jsonにリネームしてください。このファイルは omni_exts/omni.galaxy.example/omni/galaxy/example/default.json.template にあります。
      注意:これによりメタバースプラットフォームの拡張機能で読み取れ、個人設定の追加やロード間での永続化が可能になります。Galaxyインスタンスの設定後にさらに変更が加えられます。
3. ローカルワークフローエンジンサーバーの起動
   1. リポジトリの最上層にある start-galaxy.sh ファイルを実行してワークフローエンジンのインスタンスを起動します:
      「./start-galaxy.sh」
      もしファイルがここで実行できない場合、リポジトリクローンで権限が変更された場合、実行可能にする必要があるかもしれません。これは以下を実行することで可能です:
      『chmod a+x start-galaxy.sh』
      注意:Windowsユーザーは必ずWSL端末からこれを行う必要があります。これにより関連ファイルがダウンロードされ、ワークフローエンジンインスタンスが起動します。同じマシン上で動作するどのブラウザでも http://localhost:8080 で閲覧可能です。これにより 図1に示されたページが表示されます。もしそうでなければ、待ってからリフレッシュしてください。ワークフローエンジンのインスタンスの起動には時間がかかることがあります(特に初回の場合)。
      1. 一般的に、ワークフローエンジンインスタンスのリポジトリで変更を確認したい場合は、'./restart-galaxy.sh' または './stop-galaxy.sh' を実行し、 スクリプトを再度起動します。
4. メタバースプラットフォーム構成
   1. ランチャーとアプリ(この例ではOmniverse Code)をダウンロードした後、アプリを開きます。
   2. ウィンドウの左上にある 拡張機能 タブをクリックします(他のアプリでは、ウィンドウ|の下にあります) エクステンションズ)。
   3. 拡張機能ウィンドウでグレー設定ボタンをクリックしてください。すでに入力されているディレクトリがいくつかあるウィンドウが表示されます。緑のプラスボタンをクリックしてomni_extsフォルダを指すものを追加し、次のフォーマットのパスを追加します:'/galaxy-omniverse-example/omni_exts';詳細は図2を参照してください。
   4. 左側の 「THIRD PARTY TAB」欄に「OMNI GALAXY EXAMPLE」という新しいエントリーを探してください。この拡張機能のスライダーをオンに切り替え、拡張機能ウィンドウが表示されるのを待ちます。
   5. アプリが起動するたびに拡張機能を自動的に読み込むために自動読み込みのチェックボックスを選択してください。
      注意:拡張ファイルの変更は、Omniverseが拡張のホットリロードを可能にするため、ファイルを保存した際に自動的に永続化されるべきです
5. ワークフローエンジンのアカウント作成とメタバースへのリンク
   1. ワークフローエンジンのインスタンスでは、上部バーの ログインまたは登録 ボタンをクリックし、次に 「ここで登録 」を選び、ステップ1.2.2で追加したメールアドレスで詳細を入力して管理者権限を持つアカウントを作成します。
   2. APIキーを生成して、APIがワークフローエンジンと通信できるようにします。トップバーの 「ユーザー 」ドロップダウンに行ってください |優先順位 |APIキーを管理。キーを作成してコピーしてください。
   3. キーが生成されたら、空の引用符の「galaxy_api_key」 フィールドの下、Step 1.2.3で作成されたdefault.jsonファイルに追加してください。
      注意:このファイルは今後APIキーを保持します。このAPIキーは、関連するアカウントのジョブ実行やデータアクセスに使えます。公開ドメインやIPアドレスが存在しないローカル展開では問題にならないはずです。このファイルは依然として秘密扱いされ、公開リポジトリに共有またはコミットされるべきではありません(この問題を防ぐために、.gitignoreにデフォルトでリストされています)。
   4. メタバースプラットフォームアプリを再起動して、デフォルトファイルの変更を更新してください。
      注意:APIキーはサーバー設定のドロップダウンの拡張ウィンドウに直接追加することも可能ですが、これはセッション間で永続しません。

2. ワークフローエンジンでのジョブ実行

2. ワークフロー
   注:ワークフローは、入力と出力が宣言されたツールの有向グラフとして完全な処理パイプラインを符号化します。一度定義されれば、同じワークフローを任意の入力ファイルに対して再実行でき、各ツールを手動で再設定する必要がなく、すべての実行履歴と出所メタデータが自動的に取得されます。
   1. 上部のナビゲーションバーで「 Workflow 」をクリックし、右上の 「Create (作成 )」をクリックします。ワークフローの名前と説明を入力し(何でもいいです)、再度 「作成 」をクリックします。
   2. ワークフローに3つのツールを追加し、ツールメニューで関連セクションを展開し、セクション2.1で使われているツール( OpenMC Neutronics Simulation、 CAD h5mをvtkに 、 Tracks h5からvtpへ)を追加してください。
   3. ツール間のデータフローを定義します。ツールをワークスペース内でドラッグするには、各ツールの濃い青色の上部バーをクリックしてドラッグします。ニュートロニクスシミュレーションツールの Tracks(h5) 出力を、h5からvtpへのツールの tracks.h5 入力に接続します。出力の矢印から入力の矢印へクリックしてドラッグして行ってください。
   4. ワークフローレベルの入力データセットを定義します。ツールの 「Inputs 」セクションで「 Input Dataset 」を2回クリックすると、2つの入力ノードが作成されます。設定ファイル用に1つ、CAD入力用にもう1つをステップをクリックし、右側のプロパティメニューの ラベル フィールドを変更して名前を変えます。
   5. 設定ファイルとCADファイルをニュートロニクスシミュレーションツールの入力に、CADファイルをh5m to vtkツールにリンクし、 図3のパターンに従います。
   6. 右上の セーブアイコン を使ってワークフローを保存してください。
   7. ワークフローを実行するには、前述のようにトップバーの ワークフロー タブをクリックし、実行するワークフローの 再生アイコン をクリックします。次に、ツールを実行するのと同じようにStep 2.1.2のように入力を選択し、「 ワークフローを実行する」をクリックします。
   8. ワークフローが実行されるのを待つと、出力をステップ2.1.5および2.1.8と比較できます。これらは非常に似ているはずです(これらのステップによる統計的な変動に注意してください)。 履歴 内のすべての出力が緑色に変わった時点で、ワークフローは正常に実行されました。ここには入力データセットとともに4つのデータセットがあるはずです: TBR、 Tracks、 dagmc.vtk、 tracks_0.vtp。
   9. ワークフローが実行された後、一部のユーザーはワークフロー呼び出し(実行)の出所やメタデータを確認したい場合があります。これは、上部バーの「ユーザー」|ワークフロー呼び出しにナビゲートすることで実現できます。これにより、ユーザーが実行したすべてのワークフローのリストが表示され、興味のあるワークフローの下向き矢印をクリックし、BioComputeオブジェクトをダウンロードボタンをクリックしてメタデータJSONファイルをダウンロードできます。これには、実行されたツールやワークフロー、使用された入力情報などの由来情報が含まれています。
      注意:ワークフローエンジンは、すべてのワークフロー実行に対して、入力ファイルのチェックサム、ツールのバージョン、パラメータ値を含む完全な実行履歴も記録します。走行用の出所記録をダウンロードするには、 履歴 パネルを開き、右上のメニュー(下向き矢印)をクリックして「 履歴をファイルにエクスポート」を選択してください。エクスポートされたアーカイブにはすべてのデータセットと、それらを生成したステップの機械可読記録が含まれています。
      ワークフローエンジンによって生成された出所や履歴の保存は、セクション5.1で述べられているAPIを通じて自動化できます。ただし、このプロトコルでは詳細は記載されません。
3. より複雑なワークフロー
   注:このワークフローは、メタバースプラットフォームでの可視化に必要なユニバーサルシーン記述(USD)ファイルを生成するポストプロセッシングステップを追加することで、セクション2.2を拡張しています。単一のツールがDAGMC(.h5m)やVTK(vtp)からUSDに直接変換するわけではないため、パイプラインはデータを2つの多段階変換チェーンにルーティングします。CADジオメトリはH5M、STL、OBJ、USDパイプラインに従い、中性子トラックはH5、VTP、OBJ、USDを辿ります。
   1. 図 4のワークフローに従い、セクション2.2に示されているワークフローを設定する手順に従ってください。
   2. ステップ2.2.4のようにワークフローレベルの入力を定義し、 CAD DAGMC と Config Fileと名付けます。
   3. OpenMC Neutronicsシミュレーションツールを追加し、CAD DAGMCおよび設定ファイルの入力をステップ2.2.3の対応する入力に接続します。
   4. 中性子変換連鎖を作りましょう。Tracks h5をvtpに、vtpをobjに、objをUSDにツールに加え、それぞれの出力を次のツールの入力に接続します。図 4の下の分岐のレイアウトに従っています。
   5. CAD変換チェーンを作成します。 h5mをSTL、STLをOBJ、OBJをUSDツールに加え、それぞれの出力 を次のツールの入力に接続します。図 4の上部分岐のレイアウトに従います。
   6. ワークフローを保存してください。セクション3の拡張機能を通じてメタバースプラットフォームで使用可能になりました。
      注:これらの追加ステップは、ワークフローやツールの共有方法を示し、結果生成に用いられたデータや手法の再現性とアクセスを可能にします。
   7. ワークフローをポータブルファイルとしてエクスポートするには、上部バーの ワークフロー にナビゲートし、メニュー(下向き矢印)をクリックして ダウンロードを選択します。ワークフローマネージャーは .ga のJSONファイルを保存し、同じツールを持つ誰でもワークフローエンジンインスタンスで共有・利用可能です。これは上部バーの ワークフロー からインポートできます | インポート。
   8. クローンリポジトリの galaxy-tools/ フォルダを公開バージョン管理ホストにコミットしてツールを共有します。共同作業者にこれをクローンしてもらい、すべてのコンテナ化ツールにアクセスし、パブリッシャーのローカルデバイスと同じ方法で実行させましょう。
      注:パブリックワークフローマネージャーインスタンスを設定可能で、ローカルデプロイメント間でワークフローやツールファイルの手動共有を回避できます。この場合、ツールはすべてのユーザーがアクセス可能であり、ワークフローや履歴は他のすべてのユーザーに公開されます。これはこのプロトコルの範囲外ですが、恒久的な展開に関する公式Galaxy Trainingネットワークで詳細情報が見つかります。リポジトリに提供されている https://training.galaxyproject.org/training-material/topics/admin/tutorials/ansible-galaxy/tutorial.html またはdockerのコンポーズスタックをそのままサーバーに展開し、プロキシなどを通じてルーティングして公開アクセス可能にすることができます。

3. メタバースプラットフォームからのワークフローの実行

1. ワークフローの開始
   1. メタバースプラットフォームの拡張ウィンドウで「 ワークフロー取得 」(注釈2、 図5)をクリックしてください。 default.jsonに保存されているAPIキーに関連するワークフローエンジンアカウントで利用可能なすべてのワークフローがドロップダウンに表示されます。もしそうでない場合は、APIキーがJSONファイルに正しく保存されているか確認し、メタバースプラットフォームアプリを再起動してキーを認識するようにしてください。
   2. リストの 「Complex Workflow」を選択し、「 入力取得 」(注釈4、 図5)をクリックしてください。ワークフロー(ステップ2.3.2)で定義された入力フィールドは表示され、同じ名前で表されます。
   3. 各ファイルベースの入力について、「ファイルを選択し」をクリックし、ファイルエクスプローラーのポップアップを使って対応するローカルファイルを選択します:CAD DAGMC入力はdagmc.h5m、設定ファイル入力はopenmc_config.jsonです。
   4. 「起動ワークフロー」(注釈6、図5)をクリックしてください。情報セクション(注釈7)に打ち上げ確認メッセージが表示されます。ワークフローが完了した後、追加のメッセージで出力ファイルが保存され、実行が完了したことを確認します。
      注意:ワークフロージョブの進捗は、ワークフローエンジンのウェブインターフェース上で Admin | Jobsに移動して、http://localhost:8080 に監視できます。管理者アクセスが必要です(ステップ1.2.2参照)。

4. 新しいツールの追加

注意:このセクションでは、新しいワークフローツールの作成および展開のための開発者プロセスについて説明します。リポジトリのファイルシステムへのアクセスと、デバッグのためのワークフローエンジンへの管理者アクセスが必要です。既存のツールやワークフローの実行、またはワークフローの作成だけが必要なユーザーは、このセクションに従う必要はありません。

1. 一般的なプロセス
   1. ラップする前に、ワークフローエンジンとは独立してシミュレーションや処理スクリプトを開発・テストしてください。ツールラッパーは既存の作業スクリプトを呼び出しているため、ツール開発中に新しいロジックを実装することは推奨されません。
   2. スクリプトの実行環境を準備するために、スクリプトに必要なすべてのランタイム依存関係(ライブラリ、バイナリ、データファイルなど)を含むDockerイメージを作成します。
      注:このプロトコルのすべての例示ツールは、実行環境としてDockerコンテナを使用しています。Conda環境もワークフローエンジンでサポートされていますが、ここでは示されていません。Dockerに関するさらなる情報は公式ドキュメントで入手可能で、また良い入門コースはこちらでご覧いただけます:https://uomresearchit.github.io/docker-introduction/ 。
   3. 実行環境(この場合はDocker)、スクリプト呼び出しコマンド、ツールの入力、出力、メタデータを宣言するXMLツール定義ファイルを作成し、ワークフローエンジンのインターフェースで表示します。
   4. ラッパーが作成されたら、XMLとスクリプトをリポジトリ内の 新しいフォルダ galaxy-tools/ /に入れます。 galaxy-tools/tool_conf.xml で、新たに作成されたXMLファイルの相対ファイルパスを示す適切な
      タグの下にツールの新しいエントリを追加します。
      注意:このファイル名が正確にコピーされていることを確認してください。新しいツールを導入しようとする際によくあるエラーです。 tool_conf.xml エントリに誤ったパスが含まれているか、XMLファイルに構文エラーがある場合、ワークフローエンジンのインスタンスは起動に失敗します。ワークフローコンテナログのエラーメッセージを調べるには、リポジトリのルートから以下の手順を実行します:
      『docker compose logs galaxy』
      XMLの解析エラーは、ERROR loading tool
   5. ワークフローエンジンを再デプロイして新しいツールを読み込み、restart script( ./restart-galaxy.sh)から起動します。
   6. 工具が正しく登録されているか確認してください。 http://localhost:8080 に移動し、 ツール パネルでツールを見つけて、すべての入力が期待通りに表示されるか確認してください。ツールがない場合は上記の注意に従ってデバッグし、エラーがある場合はツールXML自体の構文を確認してください。これもデプロイエラーの原因になることがあります。
   7. 新しいツールは以前と同じように実行しますが、以前にテスト済みの入力で使います。 出力は履歴 パネルで緑色に変わるはずです
   8. もしツールが失敗した場合は、管理者として失敗した(赤色)出力をクリックし、 Info アイコンをクリックしてください。詳細な出力ページが表示され、stdoutとstderrストリームが表示されます。これらはツールのデバッグに関するさらなる情報のために拡張可能です。
2. シンプルな工具
   注:ツール1からツール5は、徐々に複雑な巻き方を示しています。XMLファイルおよび各ツールのスクリプトはリポジトリの対応する galaxy-tools/simple// サブディレクトリにあります。ステップ4.1.4–4.1.5およびセクション2.1に従って各ツールを展開・実行してください。
   ツール1 – 簡単なコマンドを実行する
   1. galaxy-tools/simple/1/1.xmlファイルを見てみてください。要件要素はLinux実行環境を指定します。コマンド要素には実行するためのエコーコマンドが含まれています。
   2. ワークフローエンジンインターフェースからTool 1を入力ファイルなしで実行できます。出力ファイルも定義されていないため、管理者として「 Admin, Jobs 」ページに移動し、 情報 アイコンをクリックするとstdoutとstderrストリームが表示されます。これはStep 4.1.8と同じです。stdoutストリームにはXMLファイルのコマンドから「hello world」の文字列のみが含まれるべきです。
      ツール2 – テキストベースの入力を活用
   3. galaxy-tools/simple/2/2.xmlファイルを見てみて。入力フィールドにtype="text"のパラメータ要素を持つエントリがあり、コマンドセクションは名前タグで入力変数を参照するようになりました。
   4. Tool 2を前と同じように実行します。今回は、ツールに文字列の入力を与えます。これはユーザーが望むものであれば何でも構いません。出力はステップ4.2.2と同様に表示され、標準出力はユーザーがツール入力で提供した文字列であるべきです。
      ツール3 – ファイルベースの入力の使用
   5. 再度、ツールファイルを確認してください。今では、文字列入力の代わりに、入力パラメータがtype="data"タグを使い、ファイルの使用を可能にします。これは コマンド セクションでファイルパスとして参照されており、これも入力パラメータの名前を使っています。
   6. ローカルテキストエディタを使って .txt ファイルを作成し、使わなければ実行してください:
      『ファイルからのこんにちは世界』> test_files/input.txt」
      リポジトリのルートフォルダからサンプル入力を生成するために。
   7. ステップ2.1.1で作成した .txt ファイルをアップロードし、前回と同じようにツール3を実行し、アップロードした .txt ファイルを入力として選択します。同様にstdoutも同様に表示し、 .txt ファイルの内容が表示されるはずです。上記のコマンドを使う場合、出力は「ファイルからのhello world」であるべきです。
      ツール4 – 出力をファイルに書き込む
   8. Galaxy-tools/simple/4/4.xmlを調べてみてください。 出力セクションはコマンドセクションで参照可能な名前付き出力ファイルを宣言します。
   9. .txt入力で以前と同じようにツールを実行してください。ただし、出力を管理者として表示する代わりに、この履歴パネルの通常のユーザーがこれを確認でき、成功した実行時に緑色に変わり、ワークフローエンジンでダウンロード・閲覧可能になります(前述のセクションで説明)。
      ツール5 – ツール内でスクリプトを実行する
   10. galaxy-tools/simple/5/5.xmlと付随するpythonスクリプトのgalaxy-tools/simple/5/5.py を調べてみてください。XMLでは、コマンドはツールディレクトリのPythonスクリプトを参照し、要件セクションはスクリプトを実行するためにPythonが必要なため、Python画像を参照します。
   11. ツールを同じ方法でデプロイして実行すれば、ツール4(ステップ4.2.9)と同じ動作をするはずですが、今回はコマンドではなくスクリプトを実行するだけです。
3. 複雑な工具の例
   注:この節は、第4.1節で説明されたパターンの実例として中性子ツールの開発を記録しています。関連ファイルは galaxy-tools/complex/openmc/にあります。 このパターンはあらゆるシミュレーションや処理コードにも一般化されます。
   1. シミュレーション用の実行スクリプトを作成します。この例では、run script galaxy-tools/complex/openmc/openmc_run.py 設定ファイル(openmc_config.json)を解析し、ニュートロニクス設定ファイルを書き込み、シミュレーションを実行します。スクリプトをコマンドラインから直接テストしてから、Dockerイメージにパッケージしてください。
   2. galaxy-tools/complex/openmc/DockerfileのDockerfileを使ってDockerの実行環境を構築してください。これにより、いくつかの追加パッケージが加わり、公のイメージが拡張されます。ローカルでビルドしてタグ付けするか、コンテナレジストリから参照してください。
   3. XMLラッパーのgalaxy-tools/complex/openmc/openmc.xmlを作成し、要件セクションのステップ4.3.2のDockerイメージを宣言します。入力ファイルと出力ファイルと一緒に実行するコマンド(セクション4.2の例のように)も定義する必要があります。
   4. ステップ4.1.4-4.1.7のようにツールを展開し、セクション2で使われたテスト入力を使ってツールが正しく動作しているか確認してください。
      注意:インスタンス内の残りのツール(トラックh5からvtp、 CAD h5mからvtk、 h5mからSTL、 STLからobj、 vtpからobj、 objからUSDへ)は、同じ開発パターンに従うファイルフォーマット変換器です。彼らのXMLファイルは galaxy-tools/complex/ ディレクトリにあり、さらなる参照例として利用できます。

5. ワークフローをメタバースに接続する

注:このセクションは、ワークフローエンジンのAPI統合およびメタバースプラットフォーム拡張のアーキテクチャを説明する開発者向けの参考資料を提供します。メタバースプラットフォームからワークフローのみを実行すればよいユーザーはセクション3に従うべきであり、このセクションを読む必要はありません。異なるフロントエンドアプリケーションをワークフローエンジンに接続したい開発者は、セクション5.1から始めるべきです。

1. ワークフローエンジンAPI
   注意:GalaxyはRESTful APIを公開しています。Bioblend PythonライブラリはこのAPIのより高レベルのラッパーを提供し、このプロトコルで使用されるすべてのヘルパースクリプトの基盤となっています。Bioblendはリポジトリ内の関連するDocker実行環境に自動的にインストールされます。
   1. Bioblendをインポートし、Server 1.5.2のサーバーアドレスとAPIキーで GalaxyInstance オブジェクトをインスタンス化して、実行中のワークフローエンジンに接続します。Bioblendがインストールされた環境でのPython:
      `bioblend.galaxyからGalaxyInstanceからインポート
      gi = GalaxyInstance(url='http://localhost:8080', key=)'
      注意:これはローカル展開でのみ機能します。ワークフローエンジンがリモートマシンに展開されている場合、localhostを設定済みインスタンスのアドレスとポートに置き換えてください。
   2. Galaxy-api/helper_functs.pyのヘルパー機能を使って、利用可能なワークフローの一覧表示(get_workflows)、ワークフロー入力定義の取得(get_inputs)、指定された入力ファイルでのワークフロー起動(launch_workflow)などをよく行います。関数署名や期待される返り値については、そのファイルのインラインdocstringを参照してください。
   3. アプリケーションに応じて他の機能で helper_functs.py を拡張してください。完全な参考APIは https://bioblend.readthedocs.io でご覧いただけます。
2. ワークフローをメタバースに結びつける
   注:このセクションでは、メタバースプラットフォーム拡張のアーキテクチャについてのみ説明しており、開発者は異なるワークフロー出力、追加のファイル形式、または代替のメタバースプラットフォームに合わせて適応できます。
   1. omni_exts/omni.galaxy.example/ のメイン拡張機能エントリーを開いてください。この拡張はOmniverseのベース拡張¹⁵を出発点として使用しています。その後、ステップ5.1.2で説明されているヘルパー機能APIファイルの機能をすべて追加し、ワークフローとやり取りするためのGUIを提供します。
   2. ワークフローが起動されると、生成されたデータは自動的にワークフローエンジンからダウンロードされローカルに保存され、メタバースプラットフォーム上で可視化されます。これにより、ワークフロー実行中に生成されたメタデータを保存・アクセス可能にし、シミュレーションデータの出所を把握できます。
   3. この実装はOmniverseのネイティブomni.uiライブラリを使ってインターフェースを構築しています。主な拡張子はextensionフォルダにあり、インターフェースの主な実装は omni_exts/omni.galaxy.example/omni/galaxy/example/window.py ファイルにあります。

結果

gitリポジトリで提供された入力を使ってシミュレーションを実行する場合、以下の結果が得られるはずです。

Step 2.1.3を正常に完了すると、 TBR と Tracks の出力データセットの両方が 履歴 パネルに緑色で表示され、実行成功を示します。提供された構成ファイル(5バッチ、1,000個の粒子)を用いた代表的なTBR値は約0.76で、実行ごとに約±0.01の変動があります。したがって、TBRで0.74〜0.78の範囲で得られた値は成功とみなすべきです。この広い範囲はモンテカルロ中性子の確率的性質を反映しています。この構成は速度のために意図的に小さな粒子数を使用しています。中性子の数を増やすと(現在は1,000個の粒子を5バッチで行っています)、実行間のTBR値はより一貫するはずです。Step 2.1.5の後の注記で、中性子ツール入力ファイルの設定を変更し、可能な結果の拡散を減らす一方で計算コストが増加します...

ディスカッション

プロトコルにはいくつかの重要なステップがあります。主にワークフローエンジンインスタンスの初期設定に関するもので、例えば管理者メールアドレス(プロトコルステップ1.2.2)を追加すること、これは管理者がツールやジョブパネルにアクセスするために必要です。メタバースプラットフォーム拡張(プロトコルステップ1.5.3)のAPIキーを正しく生成し、これをデフォルト値ファイルに正しく貼り付けること;また、ツールを追加する際も、起動時にロードされる際に再起動前にツール設定ファイル(プロトコルステップ4.1.6)に必ず追加し、ワークフローログからはエラーが見られない場合があります。プロトコルステップ1.5.3以降、default.jsonがAPI鍵を保持しているため、このファイルはシークレットとして扱うべきです。. gitignore に含まれているか(デフォルトで含まれている)ことを確認し、公開リポジトリにはコミットしないでください。もしワークフローエンジンのランディングページが最初 http://localhost:8080 に表示されなければ、...

材料

```html

この記事で使用された材料の一覧

名前	会社	カタログ番号	コメント
Bioblend	Galaxy Project	v1.2+	Galaxy REST API をラップする高レベルの Python ライブラリ。Omniverse 拡張ヘルパースクリプトでワークフローのリスト表示、入力定義の取得、ジョブの起動に使用されます。関連する Docker イメージ内に自動的にインストールされます。ホストへのインストールは不要です。
Docker Containers	Docker	v24.0.5	各シミュレーションと後処理ツールをその依存関係ごとにパッケージ化し、移植性と再現性を確保するために使用されるコンテナ化ランタイム。
Galaxy	Galaxy Project	v22.05	チェインされたシミュレーションと処理ツールをオーケストレーションし、REST API 経由で公開するために使用されるオープンソースのワークフローエンジン。
Git	Git SCM	v2+	プロトコルに沿ってリポジトリをクローンするために必要です
NVIDIA RTX GPU	NVIDIA	-	Omniverse でのリアルタイムのレイトレーストレンダリングに必要です（セクション 3）。RTX ハードウェアを持たないユーザーはセクション 2 までのすべての手順を完了し、視覚化には ParaView を使用できます（ディスカッションを参照）。
Omniverse	NVIDIA	Code 2022.3.3	NVIDIA の協働 3D プラットフォーム。カスタム Kit 拡張を通じて、ワークフロー出力の視覚化およびインタラクションフロントエンドとして使用されます。
ParaView	Kitware	v5.11	.vtk/.vtp 出力の検査用に、非 RTX のフォールバックとして使用されるオープンソースの科学可視化アプリケーション。
Protocol Repository	Custom	v1.0	Galaxy 設定とすべてのツールの XML ラッパー、実行スクリプト、Dockerfile、テストデータ、および Omniverse 拡張が含まれています。ステップ 1.2.1 でクローンされます。主要ファイルは直接補足アップロードとしても提供されています（I.2 を参照）。
Python	Python	v3.10+	OpenMC 実行スクリプトおよび Omniverse 拡張ヘルパースクリプトに必要なランタイム。関連する Docker イメージまたは Omniverse ダウンロードに含まれています。別途ホストへのインストールは不要です。
The OpenMC Monte Carlo Code	OpenMC	v0.13.3	核融合中性子シミュレーションに使用されるオープンソースのモンテカルロ粒子輸送コード。トリチウム育成比（TBR）と中性子トラック出力を提供します。
Windows Subsystem for Linux (WSL)	Microsoft	v2	Windows ホスト上で Docker を実行するために必要です（PowerShell で `wsl --install` を使用してインストール）。Linux および Mac ユーザーには不要です。

```