MUSCLEによるマルチスケール・シミュレーション

Joris Borgdorff, Derek Groen, and Mariusz Mamonski

マルチスケール・モデルは、現象のより広い範囲あるいはより詳細な理解を助ける。これらのモデルによって、複雑な世界、例えば、大きいが粗い基盤の上に組み合わされた細かい時間と空間解像度のモデルについて、最適に取り扱える。

マルチスケール・モデリングの古典的な例は、いくつかの原子の代わりに一つの融合した粒子として扱う粗粒子状のモデルと、構造力学的なモデルと原子論的なモデルを組み合わせる流体モデルである。両者共に、ひとつのスケールについてのかなりよい理解があるが、まだこれらの現象の相互作用については、ほとんど知識がない。これらの現象を理解するためには、これらの相互作用を理解することが鍵であり、多くの研究者は現在マルチスケール・モデル技術を活発に開発、使用している[1]。

異なる専門分野の研究者の共通の必要性によって、一般的なマルチスケール・コンピューター・アプローチのために、2010年にEuropean e-Ingrastructure MAPPER プロジェクトが始まった。このプロジェクトは、生物医学、水文学、ナノ材料、核融合、システム生物学に共通なHPCへのマルチスケールの適用を目指す。

Muscle5プロジェクトは、理論的で構成要素に基づくマルチスケール・モデリングとシミュレーション・フレームワークに同意した[2]。これは、マルチスケール・モデルを定義するシングルスケール・モデルの組み合わせ (coupling) からなる集合である(図1)。このアプローチは、ジングルスケール・モデルがしばしば既に存在する場合に、コードの再利用を予定して、配布するためのしっかりした機会を定める。そのために、カップリングはシングルスケール・モデルから切り離される。シングルスケールモデル、あるいはサブモデルは、実装、確認され、相互作用が加えられてから、隔離された状態で検証される。構成要素は、入出力ポートを通して、単純なパラメータあるいはデータセットやジオメトリーの全体を送受信する。パイプは、一つのポートからもう一つのポートまで、データを運搬する。そして、いわゆるスケールの橋渡しをしている技術を実装する。

マルチ・スケール・カップリング・ライブラリーと環境バージョン2 (MUSCLE 2, http://apps.man.poznan.pl/trac/muscle) は、フィードバック・ループによってマルチ・スケール・モデリングを実装、実行するために作られた。それを、周期的組み合わせトポロジーと呼ぶ。MUSCLEは、本当に特定分野から独立したアプローチである。それが、Amazonクラウド基盤だけでなく、ヨーロッパのいくつかのスーパーコンピューターとクラスターの上で動いていて、前述のMAPPERのアプリケーションである。これは、ライブラリーと、スクリプトによるカップリングと、実行環境から成る。

図2 MUSCLE2の階層的設計、分離した実装と、結合した実行

設計によると、サブモジュールは独立して計算する。そして、MUSCLE2によって、サブモジュールが異なるプログラミング言語 (C、C++、Fortran、Java、Scala、Python, MATLAB) で実装され、複数の計算機で動くことが可能になる。可能であれば、MUSCLE2のパイプは、共有メモリーを使う。そうでなければ、TCP/IP通信を使う。TCP/IPを使うことによって、1台のホストで動く場合と同様に、異なる計算機の間での通信を透過的にできる。中心のシミュレーション・マネージャーは、シミュレーションのサブモデルのためのホワイト・ページ・サービスをする。しかし、サブモデルが登録されたあとでは、ボトルネックの可能性を防ぐために、他のサブモデルとのメッセージ交換を分散させる。各サブモデルを別々のプロセスあるいはスレッドとして走らせることによって、MASCLE2はマルチスケール並列性を内包する。

MASCLE2はサブモデル・コードを分離し、それぞれのサブモデル・コードは、カップリング・コードから与えられた入力ポートと出力ポートだけを知っている。カップリング・コードは、どのポートがカップリングされるか知っている。この仕組みによって、利用者は、コードの再コンパイルも配置転換も必要なく、組み合わせのトポロジーを変えられる。さらに、カップリング・コードは、結局シミュレーション・コードを動かすことになる計算機資源から独立しているので、同じカップリングを複数の計算機で動かすこともできるし、別々の国に設置された計算機資源の利用さえできる。これによって、より多くの資源を利用できるだけではなく、より多様なアーキテクチュアを利用でき、それぞれのモデルの最適化に重要である。例えば、あるモデルはGPGPUから大きな利益を受けるかもしれないし、別のモデルは大量のメモリーを必要とするかもしれない。

スーパーコンピューターを使う場合には、MASCLE2は、プロセス間の直接通信をできる。しかし、多くの場合、複数のスーパーコンピューターにワーカー・プロセスが存在すると、ファイアウォールが直接の通信を妨げる。MUSCLE2において、MUSCLE Transport OverlayというTCP/IPフォワーディング・サービスによって、この問題を解決する。これは、クラスターのインタラクティブノードで走り、異なるクラスターにインストールされたMUSCLE2の間でメッセージをフォワーディングする。

大きなメッセージの速度を最適化するために、MASCLE2はMPWideライブラリー (http://www.github.com/djgroen/MPWide) を使う選択肢を持つ。これは、高性能の通信ライブラリーで、複数のスーパーコンピューターを使う宇宙論シミュレーションに使われた[3]。MASCLE2のプロセスは、スーパーコンピューターのジョブとして動くことができ、依存性が少ないが、他のプロセスと通信するためにサイト・シミュレーション・マネージャーの
働きに要求できる。これは、手動によっても、QosCosGridソフトウェア・スタック (http://www.qoscosgrid.org/) のような専用のサービスの自動処理によっても可能である。特筆すべきことに、QosCosGridは、ポーランドの電力網 (PL-Grid) のミドルウェア・ソリューションである。QosCosGridは、複数の分散したHPC資源を使って、ユーザーのスケジュールとシミュレーションの管理をできる[4]。MULCLE2は、LGPLバージョン3ライセンスが適用されるオープンソース・ソフトウェアであり、LinuxとOS X上で動く。

Mariusz Mamonski (1984 – 2013) に

本稿をMariusz Mamonskiに捧げる。彼の突然の死は我々全員にとってショックだった。MUSCLE2チームは、彼のプロフェッショナルとして、個人としての、
マルチ・スケール計算への全ての貢献に感謝する。エンド・ユーザーへの彼の献辞、ソフトウェア品質への彼の洞察、ソフトウェア基盤についての彼の経験は本当に印象的だった。彼を惜しむ。

バイオグラフィー

Joris Borgdorffは、アムステルダム大学の計算科学グループの博士候補である。マルチ・スケールおよび複雑なシステム・モデリングの形式的背景と分散マルチ・スケール計算の実用面を研究している。彼は、ユトレヒト大学において、2006年に数学と計算機科学の学士号を、2009年に計算科学の修士号を受けた。彼は、European MAPPERとSophoclesプロジェクトに従事している。

Derek Greonは、ロンドン・カレッジ大学の計算科学とソフトウェア持続性組織における、博士研究員である。彼には、マルチ・スケール・シミュレーションだけでなく、HPCと分散コンピューティングについての専門知識がある。彼は、応用分野に取り組み、スーパーコンピューターを使って、星団、宇宙論的暗黒物質構造、粘土ポリマー・ナノコンポジット材料、乱気流、人間の血流をモデル化した。彼は、アムステルダムにおて、2010年に計算天文物理学の博士号を取得した。

Mariusz Mamonski (1984-2013) は、ポズナン工業大学(コンピューター・システム研究所) で、2008年に計算機科学の修了証を受け取った。彼は、Poznan Supercomputing and Networking CenterのApplication部門で2005年に働き始めた。彼は、いくつかのEUの研究プロジェクトに貢献した。特に、GridLab、InteliGrid、BREIN、QosCosGrid、国家とヨーロッパのe-Infractructureプロジェクト、ポーランドの電力網、MAPPERである。彼の研究は、主にウェブサービス、待ち行列システム、並行した実行とプログラミング環境に集中した。彼は、Open Grid Forum Distributed Resource Management Application API (OGF DRMAA) ワーキンググループの活発なメンバーであった。

謝辞

Poznan Supercomputing and Networking Center の Bartosz Bosak 氏とKrzysztof Kurowski 氏の助力と入力に感謝する。アムステルダム大学の Alfons G. Hoekstra 氏のフィードバックに感謝する。