(4/6)
4.大規模データマネージメント光量子科学研究センターでは、レーザー加速・X線レーザー実験などの実験研究とともに、テラフロップス、テラバイト級の超並列計算機およびギガビット級のネットワーク整備を進め、物理過程解明のためのシミュレーション研究を強化していく計画である。光量子科学研究では、実験、シミュレーション研究ともに極めて高精度の時間空間分解計測が必要なため、大量のデータが発生する。しかしながら、現在のデータ転送・解析・管理技術では、研究者に大きな負担をかけて創造的研究の遂行に大きな支障をきたしているのが現状である。前章では、大規模シミュレーションについて計算の側面から問題となるところを時代比較を交えて論じた。本章では、大規模シミュレーションによって発生するデータを如何に効率良くマネージメントし、科学者の本分である創造的研究活動につなげるかを考えてみる。
まず、大規模シミュレーションの2つのタイプの計算について説明する。一方は定型処理型研究、もう一方は発見探査型研究と以下では呼ぶことにする。定型処理型研究とは、シミュレーションを行う前からあらかじめ評価する量が決まっていてその定量性をもとに研究を進めるものである。また、その特性上シミュレーションを実施する前から、観測（計測）する物理量が明確なため、統計処理や出力変数等に大きな制限を設けることができるため比較的出力データの種類は少なくサイズは小さくなる傾向がある。
発見探査型研究とは、定型処理型研究とは対称的にシミュレーションを行う前からあらかじめ評価する量は未定（もちろん物理屋のセンスで適当に当りはつけるがけっこう外れるものである）で、現象の定性的な理解を促進し、新現象の発見・原因探査を目指すものである。また、その特性上シミュレーションを実施する前から、観測（計測）する物理量が明確でないため、統計処理や出力変数等に制限を設けにくく、出力データの種類は多く、サイズも大きくなる傾向がある。
シミュレーションを実験・理論にたいして単に手助けだけでなく、第3の科学として成立させるためには、定型処理型研究だけでなく、発見探査型研究をより推進していかなければならない。以下、大規模シミュレーションを使った発見探査型研究を行うために必要な技術・条件について経験をもとに論じる。まず、前章でも述べた大規模シミュレーションからの出力についてまとめる。大規模シミュレーションを行う場合、極限にまでメモリの効率利用を図るため、必然的にプログラム内の使用メモリは、全システムの物理メモリとほぼ同程度になる。また、全システムの物理メモリを使うような大規模シミュレーションは、一般的に現在の計算能力とメモリ容量の比（FLOPS/Byte）〜１では、数日から数週間の時間が必要なためユーザによるリスタートが必要である。さらに、1TB, 1TFLOPSのマシーンを考えると、最大規模の計算はリスタート時、1TBのデータが出力される。NQSのクラスは精々10時間程度なので、すべてのリスタートファイルを１ヶ月分確保するためには、60TBを超える容量が必要である。100MB/sの速度でテープメディアにセーブするとしても60000000/100=600000秒=167時間もかかることになり、再計算によるデータの再収集は現実的でない事がわかる。したがって、再計算をしなくてすむようにデータの出力を考える必要がある。例えば、出力データの種類には、以下のような候補が考えられる。
- リスタート用：全システムの物理メモリと同程度
- 動画用：サンプリングや1Byte型データ等の利用し、1ファイルは小さいが、大量枚数の出力
- 詳細解析用：浮動小数点で出力するため1ファイルが大きく、出力回数は少ない
発見探査型研究のシミュレーションではデータ量が多く、計算時間を圧迫することになるのでできるだけ高速入出力を行う必要がある。そのため、分割ファイルによる並列入出力やマシン固有の並列入出力および出力形式を使うことになり、フォーマットなどの規格化が一般的に困難となる。したがって、計算機毎にフォーマットは異なるものと考えるべきである。現在、大規模シミュレーションで出力される動画用、詳細解析用データは、8時間のNQSのクラスで50〜100GByte、100〜1000枚程度にもなる。大規模シミュレーションでは、上述したような高速計算や高速入出力が重要な要素ではあるが、それだけではもちろん発見探査型研究はおろか定型処理型研究でさえも実質的に研究活動はできない。くり返しになるが、科学者の本分である創造的研究活動と大規模シミュレーションをつなげるためにはまだ多くのハードルがある。まさか、TBを超えるようなbinaryデータを見て、科学的発見等できようはずがない（もちろん、そんな大きなデータがASCIIであっても、一生かけてもすべてに目を通すことさえできないが・・・）。つまり、科学的認識ができるようなデータに解析加工する必要がある。「科学的認識ができるデータ」というのは、定義は難しい、というより一般的に定義しても無意味で、各々の分野で考えるべき問題である。しかし、現状で客観的にこのようなことについて科学者間で議論されることが非常に少ないこと自体が1番の問題である。さらにそれに追い討ちをかけて、発見探査型研究では、データをファイルに保存しつつ、シミュレーションの最中（ファイルベース擬似リアルタイム）に結果のサマリーを監視し、解析をしていく必要がある。実際にこのような自動化技術が伴わない大規模シミュレーションは、非常に手間が多く、創造的研究に費やすことのできる時間が極めて少なくなる。事実、数年前まではPCにデータを取り込み、適当な統計操作等を行い1枚1枚手動で画像やグラフを作っていたが、絵を作り上げる時にPCのクリックという非常に非創造的な作業に時間が費やされることになっていた。また、50〜100GByte、100〜1000枚程度にも及ぶデータを手動で解析、可視化を行い画像にしていくと、数週間はかかる。また、時間をかけて作られた画像も後日振り返ると、どのような実験、シミュレーションでどのような解析処理をかけたのかが分からなくなる可能性が非常に高かった。また、ノートやファイルのヘッダーにメモを残していても8時間で100〜1000枚程度のデータが出てくると必要な時に捜し出せないか、もしくは非常に時間がかかることになる。さらに、個人PCベースで行われている解析は、解析条件や解析結果の情報の非共有化がおこり、複数で議論しながら研究を進める時にコンセンサスが非常にとりにくくなる。このような問題を打開するためには、超並列プログラミング以外の多くの分野の技術が必要であることは重要な事実である。
光量子科学研究センターで実際に使われている大規模シミュレーションに関して、現在、どの程度の自動化が達成できているかを以下で紹介する。
0) シミュレーションのディレクトリ作成（超並列計算機とファイルサーバ）やリスタート、再実行等を自動化する。 1) 超並列計算機のローカルディスクに作られたファイルを、ファイルができ次第ファイルサーバへ連続的に自動転送する。 2) ファイルサーバへファイルが転送されたら、可視化（現在は、AVS）の実行スクリプトをそのファイルに応じて自動生成する。 3) 可視化実行スクリプトを実行する前に可視化用ディレクトリ作成を行い、続いて可視化ソフトウェアを実行し、可視化データを保存する。 4) 可視化データを、プリントアウト用、PDF等の配信用、html等のWWW用のデータに自動変換し、自動再編集する。
また、現在開発中で今年度中に開発が終わる機能としては、次のようなものがある。
5) データベースサーバとリンクして計算結果データおよび可視化データ、可視化実行スクリプトなど各種ファイルを自動登録し、検索、WWWと連係した閲覧機能を開発する。 6) シミュレーションの入力データの作成を支援するシステムをWWWとCGIベースで開発する。 7) シミュレーションの途中経過やJOBの実行状況、さらに上記の自動システムの実行状況をWWWから監視できるシステムを開発する。
さらに将来的に必要となる技術としては、
8) ディスクスペースを消費し尽くさないようファイル転送やディスク空き容量を監視し、DBと連係して、効率的なデータ退避を行うシステムを開発する予定である。 9) 最も効率的な通信路と計算機を自動的に選ぶロードバランシング機能と、どこかの通信路や計算機が不通になった場合のリダンタント機能を追加する予定である。
これらの開発において必要とする技術は次のようなものがある。高度なシェルスクリプト作成、AVS等の可視化ソフトウェアの取り扱い、可視化ソフトウェアへの自己作成ツールの追加、データマイニング的な手法による効率的なデータ解析手法、各種ファイルフォーマットへの対応、特にポストスクリプトの編集作業、各種CGIスクリプトの作成、WWWを使ったインテリジェンスなインタフェース作成、オラクル等のDBMSの取り扱い、SQLを使ったDBの作成、それからこれら複数の計算機を統括して制御する機能分散制御システム化技術などがある。
これらのシステム構成で考慮すべきところは次の通りである。プログラムは高速化や超並列化が最優先事項のためできるだけ最低限の制限で動作するようにシステムを構築する必要がある。つまり、外付け的（オブジェクト指向的？）にシステム化を進める必要がある。したがって、すべての制御はプログラムへ特殊なものを組み込まずに外部ファイル等からコントロールできるようにプログラムされるべきである。また、発見的研究過程ではプログラムの開発が日進月歩であり、このようなプログラム変更に容易に追従できるシステムでなければならない。
図5 機能分散制御システムの概念図
