gtool4/Fortran 90 tools チュートリアル
13年09月25日 豊田英司
「量的変化はついには質的変化を惹起する」
ヘーゲルの言葉らしい
私たち gtool4 の開発者グループは主に地球流体科学関係者、つまり気象・海洋・惑星大気・地球の核やマントルなどの研究者からなっています。私たちが gtool4 を開発するのは、データの嵐と呼ばれる現象にまつわる諸問題の解決としていくつかの方法論を提示し実験していくためです。
私たちは日ごろ多量のデータを交換して仕事をしています。たとえば他人が観測したデータ、理論的な計算の結果得られたデータ、それらを用いて遠くの計算機センターで計算したデータなどです。
計算機の能力向上や観測手段の開発に伴って、私たちが扱うデータは年々巨大化しています。10年前ならスーパーコンピュータでも取り扱うことさえままならなかったような巨大なファイルをノートパソコンで作成したり保存したりできるようになりました。巨大化だけではなく、取り扱うデータの種類や計算の複雑さも激増しています。
データの量の増大により、メタデータ管理の重要性が増してきました。メタデータとはデータ自身を意味あらしめるために必要なデータの総称で、たとえば物理量名称、単位、格子配置、取得法、各種パラメタなどです。データを多数の作業者で共有する場合、あるいは記憶に頼れない長期間にわたった作業においてはメタデータを保持する方法の如何が作業の速度や信頼性を左右します。
メタデータを紛失したり、個人の記憶に依存するような事態を避けるためには、データ自身がメタデータを保持するようにすべきです。このような考慮にたったデータ形式は自己記述的(★概念創案者について調べるべき)と呼ばれています。
自己記述的データ形式を設計するにあたっては、メタデータの項目リストを決めなければなりません。この項目リストはデータベースにおいてはデータベーススキーマと呼ばれています。gtool4 の目標のひとつは、地球流体科学界におけるデータベーススキーマに相当するものの標準を利用者自身によって確立することにあります。
もうひとつの gtool4 の特徴は、数値データと可視化表現を同じプラットフォームで自己記述化しようとする新しい試みです。データ形式の拡張としてとらえると、絵も描けるデータ形式といったところです。
数値データを可視化した結果ではなく、方法を保存しておきたいということがあります。このようなニーズに対して従来は、可視化エンジンを簡易な言語のインタプリタとして実装して、描画手続を順に記したスクリプトとして保存するようなアプローチが取られてきました。この方法は新しい可視化手順を生産する過程では有効ですが、インタプリタ処理系がない環境では再現不能であるとか、スクリプトとデータがばらばらになってしまうといった問題があり、保存や配布には向きません。
gtool4 では可視化オブジェクトを数値データの一種として格納できるような枠組みを開発中です。この方法によりデータが言語から独立になり、分散オブジェクト環境への適応も容易になるものと期待されます。
gtool4 は以下の3つのソフトウェアパッケージに強い影響を受けています。GTOOL3 からは理念的影響を受け、DCL と NetCDF はサブルーチンとして利用しています。
GTOOL3 は地球流体電脳倶楽部で従来から用いられているファイル形式、入出力ライブラリ、ならびにファイル操作ツール群の名称です。gtool4 は GTOOL3 の経験と反省に立って設計されていますが、コードやデータ形式は継承していません。
GTOOL3 から引き継がれた特徴:
ロジックは基本的に Fortran で記述する(数値計算プログラムとのリンクのために必要)
ファイル操作は第一にコマンドラインツールを用意する
オプションなしで適切な絵を描くクイックビューアを提供する
GTOOL3 の反省に立って新しく gtool4 で導入した特徴:
Fortran 90 の構造型を用いたデータ抽象
netCDF の採用による次元数・格子配置などの自由化
データ形式は当面 netCDF 形式によることにしました。機種依存の物理表現を吸収してくれる上に、メタデータ表現のために利用できる属性という機構が用意されているからです。したがって、処理系は netCDF ライブラリを必要とします。
残念ながらファイル形式を netCDF にできない状況も存在しますから、今後 gtool4 ではいくつかのファイル形式に対応しようと企画しています。
(少なくとも日本の)気象・海洋学界で事実上の標準として使われている GrADS という可視化ソフトウェア
人工衛星リモートセンシング関係でよく使われている HDF というファイル形式
将来的に取り扱うファイル形式が多くなっていくと、すべての形式の入出力ライブラリをリンクするのは現実的でなくなってゆくので、分散データベース化を検討すべきでしょう。NetCDF はそのときの通信形式として有用かもしれません。
gtool4 の可視化の基礎となっているのは DCL です。
DCL は線画と多角形塗りつぶしから構成される2次元的可視化表現をサポートします。ライブラリは GKS サブセットから日付の座標軸・等高線などの高水準ロジックまでの幅広い構成となっています。描画デバイスとしては以下のものがサポートされています。
Tektronix 4014 ストレージスコープ
PostScript ファイル
(UNIX のみ) X ウィンドウシステム
(Microsoft Windows のみ) Win32 グラフィックス
MacOS X への移植がなされたという報告があります
gtool4 ではこのほかにも DCL から若干の機種依存ルーチンを使っています。しかし、この機種依存性は慎重に1モジュールにまとめられていますから、グラフィックスを利用しないアプリケーションは容易に DCL のない環境に移植できます。
現在のところ、データ形式ないしはスキーマの考察は gtool4 NetCDF 規約という形式でなされています。これは NetCDF 形式を利用することを前提として、主に属性の利用法について規定したものです。
この規約には、概念スキーマすなわちメタデータにはどのような事項が記録されるべきかの考察と、内部スキーマすなわちメタデータの各事項をいかにして NetCDF 形式で格納するかの規定が含まれています。
概念スキーマはさらに、数値データ表現と、可視化表現情報に大別されます。
数値データ表現規定を開発するサイは、従来の数値データ形式(netCDF 規約を含む)で表現されてきたものの概念的和集合を抽出するように作業しました。具体的には GTOOL3, GrADS データセット, そして COARDS, GDC などの netCDF 規約が考慮されています。
可視化表現情報の規定では DCL を利用して伝統的な論文で用いられる図形表現を再現するのに必要な情報を抽出しました。
概念スキーマと内部スキーマが混在している現在の gtool4 NetCDF 規約の記述形式は望ましいものではありません。
概念スキーマは我々の数値データに関する慣習的操作体系ないしは知識体系を記号化明確化したものです。したがって、ファイル形式(内部スキーマ)がどのようなものであっても共通であるべきものです。ファイル形式に依存しない属性リストとして概念スキーマを記述し、ファイル形式ごとの属性表現規則は内部スキーマとしてまとめることによって、規定の簡潔さを保持しつつファイル形式間の可搬性を確保できると期待できます。
概念スキーマ開発については2つの事項が保留となっています。そのひとつが物理量の単位をいかに演算するかです。
NetCDF ユーザーズガイドでは udunits ライブラリが受理する単位を用いることが推奨されています。udunits のマニュアルは単位の表現方法を規定しています。ライブラリは文字列表現と(C の構造体による)内部表現との相互変換と、加減乗除演算を実装しています。
現在のところ udunits を Windows に移植できていないため、加減乗除演算が udunits の実装どおりでよいかに関する検討は実施されていません。udunits の可搬性を見切って Fortran 90 で独自に互換品を実装しようというアイデアもあったのですが、まだ実行されていません。
概念スキーマ開発に関する最大の保留課題は情報の履歴管理です。
NetCDF ユーザーズガイドでは history 属性にファイルの履歴を示す文字列値を書き込むことを推奨しています。history 属性の構造は線形で、ファイルが作られてから改変を経るごとに追加されていくような構造になっています。
gtool4 NetCDF 規約の作業グループは GTOOL3 の経験から、2項演算子などについては線形の履歴を当てはめるのが無意味であることを認識していました。また、長すぎる文字型属性値は特に Fortran での取り扱いが困難です。そのため、作業グループでは木構造の履歴を表現する方法を開発することだけを決定しましたが、まだ試案は作成されていません。
データを読みとって書き出す演算において、次元の意味づけを
正しく保持するようなメカニズムは作れるだろうか?
簡単のため出力変数を一つとします。すると演算は入力変数の
数によって単項演算、二項演算、三項演算...
と分類されます。
単項演算子については大した問題はありません。
足し算みたいな要素毎の操作ならばもとの次元セットをコピーすればよいし、
平均のように次元を減少するものについても残った次元セットをコピーすれば
いいでしょう。つまり、要請は簡単で、演算の過程で常に次元セットを覚えて
いればよいのです。ま、メタデータを紛失しない義務くらいは要請してもいいでしょう。
二項演算子になるととたんに悩ましくなります。
要素毎操作に限定して考えることにすると、次元数が一致しなくてはいけない
くらいは自明ですが、両者の次元リストの対応をどのようにとるかというところが
工夫のしどころというか悩ましいところというか....
堀ノ内さんはメタデータに頼らず、次元の宣言順序と次元長(格子数)だけから
対応が決まるアルゴリズムを提案しました。
おそらく ruby の NumArray
クラスにもその考えが活かされているか、その予定なのでし
ょう?
この方法は簡明で、実装も容易でしょうが、
健介さんの指摘された問題がまさにあてはまってしまいます。
私はメタデータに頼って意味づけによる対応を作る方向を模索しました。
たとえば GrADS のスクリプトによる四則演算が便利なのは、
すべての次元が経度/緯度/高度/時間のいずれか
として表現されなければならないという制約があるために、
意味による対応づけによる演算が実装できているからです。
同じ機能を、時空間に限定しないあらゆる配列添字について拡張すること
こそが、我々がなすべきことではないでしょうか。
現在検討しているのは以下の2本だてです。
* 意味による対応作戦
- 加算可能な単位をもつ次元を対応させる
(これで位置と時間や電圧の対応が排除される)
-
一意に決まらない場合、単位名が一致する次元対を優先する
(どこかのコンベンションでは経度と緯度に
degree_N と
degree_E
を推奨していたが、この目的で利用できる)
-
まだ一意に決まらない場合、同じ次元名もつ次元対を優先する
(long_name
による対応、long_name が "latitude" と "magnetic
latitude"
を
同一視させる対応、などが議論されていた)
* 外延的対応による作戦
- 次元長
- 宣言順
(これらをどう使うかは
NumArray との協調をもつべきだろう)
これらは選択されるべきだし、意味による対応作戦は
メタデータの誤りなどで失敗しうるので、意味による対応が失敗したら外延的対応を
試みるというのもありかもしれません。
実装は可視化構造の Fortran による表現を作成した。
自己記述性によるメタデータ管理の省力化を検証するためには、今後各種データ処理におけるメタデータの自動処理実験が必要である。