【まだ書きかえます。どこをいつ書きかえたかを必ずしも明示しません。】
- 0 -
所属する研究機関の職員が共通に利用する計算機が、来年度に更新される見通しになって、その計画について職員からの意見募集があった。
わたしは、更新後の計算機の利用者にはならない見こみなので、発言するのは遠慮しておこうとも思ったのだが、来年度あらたに来る人には発言する機会がないことも思いなおして、意見を書いて送った。
このブログには、表現をやや一般的になおして、出しておくことにする。
なお、わたしは、[2010-07-30の記事]で、次のように述べていた。
所属している機関の計算機更新構想の話を聞いて、次のような意見を言いたくなった。「機関共通の計算機の必要性は、計算をする機械としてよりも、職員間でデータを共有する場としてのほうが大きいのではないか。」そのことを文章にしようとしたのだが、頭がそれと関係はあるが焦点がずれたところに向かってしまったので、そちらを先に書き出してみる。データ共有の場についてはいずれ別の記事にしたい。
しかし、その更新のときは、「別の記事」は書かずじまいで来てしまい、次の更新の話が出てきて、やっと思い出したのだった。
- 1 -
地球科学で、計算機の能力をいちばん多く使う仕事は、数値シミュレーション、および、数値モデルに観測データを取りこむ「データ同化」だ。
そこで、そのような仕事を念頭において、「地球シミュレータ」という計算機が設置されている。その初代は特別に開発された計算機だったが、現在は3代めで計算機会社の製品が納入されたものだ。地球シミュレータを利用できるのは、利用計画を提出して審査をとおった研究課題にかぎられる。しかし、逆に言えば、審査をとおりやすい研究課題ならば、地球シミュレータの計算時間を割り当ててもらえることを期待できる。
地球シミュレータが別にあるという条件のもとでは、研究所内共同利用計算機の機能としては、狭い意味の計算機能よりも、職員間のデータ共有の場の提供を重視するべきだと思う。
科学計算のうちには、大量の計算時間を使って、わずかな個数の数値を求めればよいものもあるようだ。しかし、気候に関するシミュレーション型研究ではたいてい、シミュレーション計算自体は結果を(テラバイトの規模のデータ量の)ファイルとして書き出して終わり、その結果を解析する別の計算をして、やっと研究成果になる。この「解析」の作業は、統計処理や図化を含むが、そこで、多数のシミュレーション結果をあわせて使ったり、比較のために、別の由来をもつ観測データや同化プロダクトをも持ちこんで使うことが多い。
そのような統計処理や図化の処理は、研究者個人や小さなグループが保有する計算機でも可能だ。しかし、同じシミュレーション結果や観測データや同化プロダクトを多数の研究者がそれぞれ管理するのは、ディスクスペースもさることながら、管理にあたる研究者の能力のむだづかいとなる。データを共用計算機につながったストーレジに置き、各研究者が必要な部分だけを切り出して手もとに移すのが適切だ。
ここで「切り出し」と書いた処理には、地域や時間範囲の選択、間引き、平均化、その他の統計値計算、違った格子系の間の内挿操作などが含まれる。シミュレーションに比べれば演算数は少ないが、無視はできない計算処理が伴い、そこを高速にすませられることが、研究全体の効率を高める。
したがって、共用計算機に対する研究者からの需要としては、計算性能よりもストーレジの容量とアクセスしやすさが優先するのだが、ストーレジだけに特化したシステムではなく、ストーレジの読み書きを伴う計算処理の能力ももったシステムがほしいのだ。
- 2 -
研究者間のデータの共用の需要は、大きく分けて、次のようなものがある。
- (1) 共著論文になるような共同研究に従事するグループ内で、研究進行中の(対外的には非公開の)データを共有する。A氏が処理した結果をB氏が処理する、その結果をC氏が観察する、といったことを、データを同じ計算機システムのストーレジに置いたまましたいのだ。
- (2) 研究所外から取得した使い道の広いデータセットを、所内の複数の研究者が利用できる形で置く。
- データが有料だったり利用に許可が必要だったりするが、サイトライセンスをとれる場合には、とっておくと便利だ。
- 無料公開であっても、データが大量であったり管理がめんどうな場合は、共用計算機システムのストーレジに置いておけば、ディスクスペースについても管理の手間についても節約になる。
- (3) 研究所内で作成され、広い使い道があると期待されるデータセットを、所内の他のグループの研究者も簡単に利用できるように、共用の場所に置く。
このうち、ストーレジの需要量が大きいのは、おそらく(1)だと思う。ただし、そのデータは長期保存の必要がない部分が多いと思う。時間の重みをかけると、(2)(3)が重要になってくると思う。
- 3 -
2節の箇条書きの(2)に関しては、過去の成功経験と失敗経験がある。
わたしが1999年に非常勤、2000年に常勤として参加した時限の研究組織には、シミュレーション型数値計算向きの「スーパーコンピュータシステム」のデータサーバーという名目だったが、Unix系OSの汎用計算機があり、それに、データアーカイブ装置がついていた。データ解析をおもな活動とする研究者にとっては、こちらが主の計算機だった。当時のデータアーカイブ装置はテープを使っており、呼び出しに分(minute)単位の時間がかかるものの、プログラム上はpath名を適切に書いておけば、ディスク上にあるデータと同様に読み書きすることができた。これは、当時としては、大量データを読み書きして比較的単純な統計処理や図化処理をする研究者にとって、非常に使いやすい計算環境だった。
さらに、この時限研究組織には「データバンク」という制度があって、組織内の多数の研究者が参照するデータを、共用計算機のデータアーカイブ装置に置いて共同利用していた。そのうちには(3)にあてはまる組織内のプロダクトも少しあったが、大部分は(2)の他組織由来のデータセットだった。当時、多くの研究機関では、量が多い「再解析データ」や衛星観測由来のデータプロダクトは、オフラインのテープで持っていて、使う人がテープを持って計算機に読みこませる必要があった。しかし、この組織の共用計算機では、path名を指定するだけで、テープに手をふれずに読めるので、とても楽をすることができた。
それから、この時限研究組織は常設の研究所に統合された。時限研究組織の計算機システムも、更新の機会に研究所の共用計算機システムに統合された。研究所共用計算機システムにもアーカイブ装置がついていて、(1)の目的に関する限り、使いがってはほとんど同じだった。
しかし、計算機システムの統合の際に、データバンクは取り残されてしまった。それまでにデータバンクが持っていたデータを共用計算機のストーレジに移すことはできた。しかし、それ以後、時限研究組織を引き継いだ研究所の部門で取得した(2)のデータは、部門がもつ、データストーレジ機能だけのサーバーに置かれ、それを使って計算をしたい研究者は、自分でデータを転送する必要が生じたのだ。所内ネットワークによる転送だから、テープを扱うよりはだいぶましではあるが、共用データが共用計算機上で簡単に読めるというメリットが失われた。
さらに、5年の中期計画の切れめごとにくりかえされる法人内組織scrap and buildで、法人内の組織名が変わってしまい、旧組織のどの機能が新組織のどの部署に引き継がれたかもわかりにくくなった。サイトライセンスが継続されているかどうか不確かになり、また、それを確認したりデータ提供者と交渉したりするスタッフもいなくなり、データバンクは消えていった。(わたしは、なんとかしたいと思ったものの、実質的になんともできなかった。) 現在では、研究グループがそれぞれ参照するデータを管理しており、ディスクスペースも研究者の手間もむだが多くなっている。
今後、データバンクを、研究所全体で持つのがよいのか、部署ごとに持つのがよいのかは、よくわからない。しかし、いずれにしても、次期共用計算機システムを設計する際には、ストーレジの一部は、このようなデータバンクを構築することが可能なように、あらかじめ考えてほしいと思う。
