gtool4/Fortran 90 tools チュートリアル
2000年12月18日 豊田英司
gtool4 は多次元の数値データを可視化・操作するためのソフトウェアです。可視化ツールと呼ばれるソフトウェアは既に世の中に数多くあります。しかし gtool4 が造られるべきだと私たち（gtool4 の開発者）は考えたわけです。これからそのわけ、つまり gtool4 を通じて私たちが実現したいと思っている目標を紹介します。
最初に多次元という言葉がでてきました。私たちは、規則格子データだけではなく、観測や不規則な配置をもつ格子データでよく見られるように、位置がデータとほぼ同数のデータについても統一的な取り扱いができることを目標としています。
現在のところ、ファイル形式の仕様をとにかく決めただけで実装といったら線グラフくらいしかないのですが、一般的な取り扱い方が決まれば実装がでてくるはずです。
私たちは主に地球流体科学関係者、つまり気象・海洋・惑星大気・地球の核やマントルなどの研究者です。私たちは日ごろ多量のデータを交換して仕事をしています。たとえば他人が観測したデータ、理論的な計算の結果得られたデータ、それらを用いて遠くの計算機センターで計算したデータなどです。
計算機の能力向上や観測手段の開発に伴って、私たちが扱うデータは年々巨大化しています。10年前ならスーパーコンピュータでも取り扱うことさえままならなかったような巨大なファイルをノートパソコンで作成したり保存したりできるようになりました。巨大化だけではなく、取り扱うデータの種類や計算の複雑さも激増しています。
むかし「量的変化はついには質的変化を惹起する」といった人がいたらしいですが、そんなことをいわなくても多すぎるデータに複雑すぎる処理をしていれば人間の脳はパンクします、といえばわかりますね。一人でやっているならば何とかなっても、他人とデータを交換したり、他人に仕事を引き継いだり説明したりするのが大変になります。あるいは自分でも忘れてしまいます。これは「まじめに理解しないからいけない」などといった精神論ではどうにもならないことです。
計算機ネットワークの進歩に伴って「仮想研究室（バーチャル・ラボラトリ）」なんてことをいう人がでてきました。でも、もともと気心の知れた（同じ研究室ってことね）人がやむを得ず分散するだけじゃなくて、ネットワークを使って人を集める真の仮想研究室を構成するためには、ネットワークを使って集めたデータ・知識・プログラムがすぐに自分の役に立つようにする必要があります。
そこで、データの形式、データを使った知識の表現、データの処理系などなどについて新しい標準を造ってゆかなければならない、と私たちは考えるわけです。
それでは、何を便利にすればいいのでしょうか。私たちは以下のような必要があると考えます。
可搬性
ファイルを別の機械に持っていったときに、バイトオーダーだとか浮動小数点形式だとかなんだかよくわからない機種依存性によってファイルが読めなかったという経験はありませんか? そのたびに変換プログラムを書くのは大変です。ファイル形式は機種非依存なものにしたいですよね。
自己記述性
ファイルを他人からもらったとき、あるいは自分で昔作ったファイルを探し出して使おうとするとき、一体どのようにしてデータを解読してよいのかわからない、といった経験はありませんか? 解読のしかたがわかっても、作図の仕方がわからない。あの文書に描かれた（ような）図がほしいだけなんだけど... ということもよくありますよね? こういった情報はデータといっしょに流通させれば、もらったファイルがすぐに使えます。
ネットワーク透過性
データが複数のファイルからなるときに、いろいろなところで作業するので一部のデータを共有したいということがありますよね。そういうときにネットワーク経由で自動的にデータ取得ができればよさそうですね。いまどきですからファイル共有プロトコルは HTTP になるでしょう。すると、ファイルに外部参照機能をつけるときは、ファイル名に閉じていないで URL に一般化したほうがいいでしょう。このように、同じことをするならネットワーク環境への拡張を考慮することを、私たちはネットワーク透過性の考慮と呼んでいます。
MS-Windows や MacOS に代表されるビジュアルシェル環境では、データファイルの種類に応じてビューワプログラムがシェルに登録できて、あとはファイルのアイコンをクリック（Windows ならダブルクリックですが）するだけでプログラムが起動されます。たとえば WWW のリンクのひとつとしてデータファイルを指示して、クリックすれば図が表示され、ダウンロードすればそこから計算が開始できる、そんなことも可能になるでしょう。
こういうところで省力化が図れれば、データ形式に関して情報提供をする手間がまったくなしで作業人員が追加できることもあるでしょう。そんなわけで gtool4 プロジェクトは
というキャッチフレーズを掲げています。
私たちは実現の仕方にもこだわりを持っています。
オープン/フリー
私たちは仕様をオープンにします。私たちはできる限りコードを自由に配布できるようにします。それはユーザの皆さんのお役に立つことであると期待していますが、私たち自身のためでもあります。
Linux や X11 の成功をみてもわかるように、大規模なソフトウェアが健全に成長していくためには、オープンな開発によって人材もアイデアも取り入れていくことが有効であると私たちは考えています。
オブジェクト指向
一般的過ぎる書き方ですが、オブジェクト指向とは、システムの構成要素をオブジェクト（対象、もの）としてとらえ、そのものの振る舞いとしてシステムを記述しようとする考えです。gtool4 の目標はまさしくデータの自律的管理なので、オブジェクト指向がもってこいなのです。プログラムコードにも、コマンド仕様にもオブジェクト指向の考え方がずっと流れています。
もちろん、オブジェクト指向の特徴といわれるものをなんでもかんでも突っ込んであるわけではありません。たとえば Fortran90 実装ではコードとデータの統合、情報隠蔽などは活用しましたが、継承などにはこだわっていません。
対話的処理とバッチ処理の両方を指向
可視化を考えます。単純にスケールアウトしない程度の間隔で等値線を描けばいいだけならば対話的なソフトウェアに完全におまかせしておけばいいでしょう。しかし、実際には作図の目的からそうはいかないことが多いのです。たとえば、複数の断面を繰り返し描画するさいに等値線間隔が同じでないと比較できませんし、もっと特定した数値の等値線だけを引きたい場合もあるでしょう。
このような細かい注文は最初は対話的に見出すのが好ましいですが、多数回繰り返し処理をすることを考えるとバッチ処理がしたくなります。gtool4 はその両方を視野にいれて開発を進めています。