吉村先生 と 当社 ADVC事業部長 大山知信

プロジェクトの始動、持てる知識を一挙に集約

―プロジェクトの開始にあたって、ご苦労されたことはありましたか。

プロジェクト始動にあたって、研究室で進めていた領域分割型の解析コードやメッシュ生成、可視化等のコードを参照しそれらを改良したり、コードを新規に書き直したりという開発方針の決定を行いました。

出来上がっているコードをいきなり書き換えることは難しいので、コードを理解するところから開始しました。他にも、システム全体のアーキテクチャ、大学メンバー・企業との分担の割り振り、非均質な混成部隊の調整の進め方…など、プロジェクト開始時に考えなければならないことは多くあります。

ADVENTUREプロジェクトに腰を据えて取り組みたかったので、プロジェクト進行中の5年間の間は、学協会での仕事などほとんどすべての仕事を断らざるを得ませんでした。

自分の中でそれまでに蓄積していたあらゆる知識やアイデアを一挙に集約して、ADVENTUREシステムのアルゴリズムやシステムの仕様を決めてきたのは一つの重要な点と考えています。

自由な環境の中でも、きちっとした定義で

―プロジェクトミーティングはどのくらいのペースで行っていましたか。

ADVENTUREプロジェクトでは、ひと月に1回のペースでミーティングを開いていました。同時期に、地球シミュレータに向けたプログラムを開発するプロジェクト（GeoFEM）も動いていて、矢川先生はそちらにも代表として携わっていました。GeoFEMは東京大学助教授（当時）だった奥田洋司先生が開発リーダーを務め、その流れは、現在のFrontISTRにつながります。

そのプロジェクトは地震予測に関わるもので、汎用コードの高速化についてゼロから考えるものでした。厳密な開発方針を立てて、週に1度のペースでミーティングを行っていたようです。それに対しADVENTUREプロジェクトでは、産学の多様なメンバーが参加する混成部隊でしたので、上から下まで完全に隊列を整えて開発を行うのではなく、個々人がそれぞれの役割を果たしながら効率的に連携することを重視し、自由な環境の中でもしっかりと動くソフトウェアを開発できるスタイルが良いと考えていました。

そこで、最初に分散協調型という大きな方針を立てた上で、モジュールと称する個別コードをしっかり分けて開発担当者を決め、各モジュールのIOだけは全体で厳密に定義していく方針にしました。コードの中身については十分にチェックをしてフィードバックを行いましたが、IOがしっかりしていれば、モジュール内部の個別の設計や実装については担当者の自由な部分を残す、という方針で開発を進めたのです。

当時から様々な並列計算機が登場していましたので、プログラム動作時の並列環境が今後どうなるかは予測不可ですし、コードが扱うデータは従来よりも2～3桁上の巨大なものになります。プロジェクトとしては個々のモジュールの細部にこだわるというより、IOをバイナリデータとして扱うことや、個々のモジュール開発の進めやすさや移植性、保守性を優先させる、そういう方針です。

今では驚くかもしれませんが、昔はメッシュデータの節点や座標を一つ一つ数値でチェックしていた時代もありました。けれども億単位のデータでそれはできないので、IOは速度重視のバイナリデータに統一したのです。

このように、ADVENTUREのシステムでは各プログラムがモジュール型になっていること、共通のIOを使用していること、ADVENTUREシステムでの共通言語と決めたC言語で書かれていること、それらを重要視しました。

スパゲッティコードにならないために、骨格をしっかりと

―並列化プログラムを開発する上で、気を付けるべきことについてお話ください。

以前はそれまで実績のある逐次型のコードをベースとして、それを並列化することが通常でした。通常汎用コードでは、ユーザーが求める新しい機能をどんどん追加していきますので、それに伴って複雑なスパゲッティコードになってしまいます。そうなると、逐次型コードとしてとりあえず動きはするけれども、並列化することが極めて難しくなってしまうのです。

また、一つのコードの性能向上に凝りすぎた場合も、スパゲッティプログラムになってしまいがちです。そうなると、とてもじゃないけどメンテナンスできない状態になります。

当時の汎用コードを例えて言うと、ユーザーインターフェースやユーザビリティー機能向上のための部分が、分厚いお化粧のようになっていて、プログラム本体をいくら並列化しても分厚いお化粧のところは手つかずの状態であったため、トータルとしては全然並列化できないわけです。

商用コードのADVENTUREClusterに比べるとオープンソースのADVENTUREは機能的には十分ではありません。その理由はADVENTUREに多くの機能を付けた場合にスパゲッティプログラムとなり、そこからは、今後の新しい並列計算機環境に向けて、並列コードとして開発を続けることが難しくなってしまう状況が予測されるからです。

そうならないために、骨格の部分、その中でも特に並列化に関する骨格をしっかり作ることを重視したのです。ADVENTUREの中核並列ソルバーには、バランシング領域分割法を前処理とする階層型領域分割法が採用されていますが、並列化に必要な骨格の部分はなるべくスケーラブルできちっとしたアルゴリズムにしておき、それを壊さず新しい機能を追加するためにはどうすればよいかを深く考えました。

並列計算におけるスケーラビリティ（拡張性）を重視し、そのためにたくさんのプロセッサから構成される最新の並列計算機上でもきっちり動くようなアルゴリズムを開発し実装することを基本とする。その上にユーザーが望む解析機能を入れるには一体どうしたら良いのかというところで知恵を絞る、ということを課題ととらえていました。

オープンソースとして「やるべきこと」と「やらないこと」

―具体的に並列化のために判断を要した点などがありましたら教えてください。

中途半端に手を付けてしまうと、開発リソースの制約から、その後の開発が厳しいと予測される部分については、あえて手を付けない判断をしました。例えば、並列環境で稼働する汎用的な接触アルゴリズムの実装は泥沼に入ると感じていました。接触解析の基本ともなるMPC（Multiple Point Constraint / 多点拘束）機能の実装については、日本大学准教授の宮村倫司先生が新規アルゴリズムを開発し、ADVENTUREに実装しましたが、接触までは実装しない判断をしました。

このように「やるべきこと」と「やらないこと」を、重要度と困難度について自分たちの身の丈や状況を考えて優先順位付けし、明確な意思で決定していったのです。結果的にADVENTUREのオープンソース版は限定した機能とし、学習、あるいは利用しようとする方々から見て比較的参考にしやすいものとなりました。そのことが、地球シミュレータ、京、富岳と続く先進的な並列計算機環境への速やかな適用を容易にすると同時に、ADVENTUREClusterのような汎用コードとオープンソースコードとの差別化にも繋がっています。

各モジュールの開発に関しては、アライドエンジニアリングから何人かの技術者にそれぞれに入ってもらい、大学側メンバーと一緒に開発を進め、アルゴリズムやどういった機能開発を行うかを一緒にチェックするという形で作業を進めていきました。

秋葉さんも一押しであった、アライドエンジニアリングの大山知信さんはプロジェクト２年目から参加し、ソルバーの中核開発者として活躍していただきました。場所が離れていると日々の細かい打ち合わせができないので、共同研究員として週に何度か研究室まで来てもらっていました。

このようにOn the Job Training（オンザジョブトレーニング）という形で、アライドエンジニアリングの方々には密接に関わっていただき、アルゴリズムや実装法、開発思想もこのような環境の中で伝達されていったのです。

―当社では、構造解析に一通り携わらせていただきましたね。

そうでしたね。その他にも先ほどお話した、地震予測に関わるプロジェクト（GeoFEM）のメンバーとの合同勉強会も開催しました。当時の大学院生を巻き込んでそれぞれ骨格を作り、その他のメンバーも含めてシステム全体として一緒に開発を進めていきながら、2002年に未来開拓学術研究推進事業のもとでのADVENTUREのプロジェクトが終了しました。

ADVENTUREのオープンソース公開後、1年経つか経たないかのタイミングでアライドエンジニアリングの方でもADVENTUREClusterがリリースされました。 時間を置かずにADVENTUREClusterをリリースできたのは、最初の段階からADVENTUREプロジェクトで一緒に成果を出しながら、さらにアライドエンジニアリング内で踏襲して開発を進め、独自の並列化手法であるCGCG法を実現できたからではないでしょうか。