gt4f90io gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ

Presentation on theme: "gt4f90io gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ"— Presentation transcript:

1 gt4f90io gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ
○ 森川 靖大 (北大・理) 小高 正嗣 (北大・理) 石渡 正樹 (北大・地球環境) 林 祥介 (北大・理) 『北海道大学の森川です。我々のグループでgtool4 プロジェクトの一環として開発しているgt4f90ioというFortran90 のI/Oライブラリに関してお話させていただきます。』

2 背景：データの嵐 様々な形式のデータが多量に氾濫 データ参照コストの劇的な増加 衛星観測データ 数値モデルデータ
ネットワークの発展で活発に流通 データ参照コストの劇的な増加 「何」のデータ？ 「いつ」, 「どこで」, 「誰が」作ったデータ？ どうやって「見る」の？ 『近年、まあここ10年ぐらいかと思いますが、様々な観測機器の開発やコンピュータの進歩によって様々な種類のデータが大量に出来、その上ネットワークの発展のお陰でそれらが簡単にやりとりできるようになりました。』 『このようにいろいろなデータを容易にやりとりできるようになった事ことはありがたいのですが、反面、』 『そこにあるデータがどこの誰が作った何のデータか、というのを知る手間が劇的に増加してしまいました。扱うデータの種類も数も限られていた昔は良かったのですが、このようなデータの嵐に見舞われた現状では、このコストがバカにならなくなってきたわけです。 』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 【コンピュータでデータのサイズが増える。観測技術で種類が増える。ネットワークで手に入ってしまう。】 『ではまず、このライブラリを作る背景となった近年の動向をお話します。』 『近年、地球科学の分野では多様多種なデータが大量に出回っています。その主な原因は以下の3つで、一つ目はコンピュータの著しい進歩です。この進歩によって、数値モデルで吐き出されるデータのサイズや数、そして種類が莫大になっています。二つ目は観測技術の目覚しい向上です。最近は数多くの観測衛星が飛び交い、様々な種類のデータを送ってくれます。そして3つめがネットワークの急速な発展です。今までは、例えデータがあったとしても、そもそも手に入れるのが困難だったわけですが、ネットワークの発展により、かなりの量のデータが容易に手に入るようになりました。』 『このような、多様多種のデータを容易に入手できるようになった事自体は歓迎すべき事なのかもしれませんが、逆に新たな問題が発生することとなりました。』 『それが、データ参照のための、コストの劇的な増加です。ここで言うデータの参照のコストとは、ファイルの形式がどんなものであるか？ ファイルの中身はなんなのか？ そして、どのようにこのファイルを扱うか？ ということを知るためのコストです。扱うデータの種類も数も限られていた昔は良かったのですが、近年のこのような状況では、このコストがバカにならなくなってきたわけです。』 ・お話し用ノート 『同じデータ形式の数も増える。種類も増える。サイズも増える。』 『紙に書いとけば?』 → 『僕には無理』 『データベースを作ったら？』→『別のものを用意して、それに頼るようなシステムにしたくない』 『それでは、まずこの gt4f90io というライブラリを作る事となった背景からお話させていただきます。現在、地球科学分野では…となっています。それ自体は、データを手に入れるのが大変だった昔に比べれば、実に歓迎すべき事といえるのかもしれませんが、結果としてデータを参照するためのコストが飛躍的増加する結果となっています。データの参照コストとは、具体的に言うと…。昔は扱うデータも限られていましたので、一つ一つのデータ形式を扱うのが多少手間でも、たいした問題にはならなかったのですが、…』 ディレクトリがあふれ返る。 GCM、EBM、CRM、IDEM、観測データのそれぞれの比較が必要となる。それらによって生成されるデータが異なる形式の場合には、それぞれを扱うためのツール (環境) が必要となり、面倒である。それらを簡単に比較できるためには同様の形式のデータに書き出すことにし、同じツールを共有するのが便利である。 背景 コンピュータの進歩とネットワークの成長により、科学者は巨大で多種多様な形式のデータをより効率的に扱う必要と直面している。 共通のデータ形式を作り、ソフトウェアを共有することで、それらの労力を軽減できる。 地球流体 (すなわち、大気、海洋、地球内部)を扱うデータのためのソフトウェア環境 “gtool” に関して報告する。 『これまでの取り組み』 = 『gt4f90io に先立つ取り組み』

3 効率的なデータ相互参照が必要 数値モデルを用いた惑星大気の研究では… 階層的モデル群による アプローチ 地球大気との比較
『こういったことは、いろいろなところで問題になっていると思いますが、ここで僕らがやっている惑星大気の研究での問題を紹介させていただきます。例えば僕らは、惑星の現在と過去の大気の比較や、地球と他の惑星の大気の比較、といったことを数値実験しています。』 『モデルも一つではなく、鉛直1次元の放射対流モデル (左上)や南北1次元のエネルギーバランスモデル (EBM)や、2-3次元高解像度モデル(右上)、3次元のGCM(左下)といったものを用いています。』 『いろいろなモデルで実験した結果、いろんなデータの比較を何度もやんなきゃいけません。「データがパッと見れ」たり、次元の異なるデータでも「パッと比較できる」ために、こういった参照コストを抑える事が非常に重要といえます。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーー 『このような手間を気にするのは、どんな研究をしているか関係してます。僕達は惑星大気の研究をしているんですが、地球や火星の、現在そして過去の気候や気象に関して、数値モデルによるシミュレーションしてます。』 『具体的には鉛直1次元の放射対流モデル (左上)や南北1次元のエネルギーバランスモデル (EBM)や、2-3次元の雲解像モデル(右上)、他にも3次元のGCM(左下)による数値実験を行っています。このような大規模なプロジェクトになりますと、数多くの研究者の間でデータの相互参照が頻繁に行われます。このような時、誰でも、「データがパッと見れ」たり、次元の異なるデータを「パッと比較できる」ことが必要とされています。』 ≪以下、DM2ゼミ用≫ 『このようなコストを気にするのは、そもそもの研究スタイルと大きく関係しています。僕は、というか一人でやるわけではないので僕んとこの研究グループでは、というべきですが、地球や火星または金星の大気現象の物理的メカニズムの違いについて知るため、現在や過去の気候や気象に関して、数値モデルによるシミュレーションを行います。』 『具体的にモデルといっても色々ありまして、鉛直1次元の放射対流モデル (左上)や南北1次元のエネルギーバランスモデル (EBM)や、2-3次元の高解像度の対流モデル(右上)、全球での3次元の大気大循環モデル(左下) といろいろあります。実際の大気現象に近づくのは、複雑な3次元のモデルで重要ですが、単純なモデルはメカニズムをシンプルに反映できるため、物理的な考察には便利で、これもまた重要です。』 ≪何に注目して実験しているのか？≫ ・地球に関してはいろいろ理解してきたつもりでいたものの、他の金星や火星といった地球型惑星でもそれは同様なのか比較したい（水星は大気が無いし、木星型惑星は地面が無いので話が違ってくる） ・地球を軸にしないと、経験が無いのでわからない。 （地球との比較惑星的理解を辿るのが自然） ・ 地球で得られた知見とは地球のみのものなのか？または地球型惑星共通のものなのか？ ・ 地球の常識は火星の常識なのか？ 『by Y. Takahashi』 ・ 物理的な考察をおこなうための数値モデル （気象予報とは違うよ → 現在業界では気候予測『特に温暖化』へ） ・簡単なモデルは物理との対応が取りやすい ・現実との対応は複雑でいろいろな要素が混ざった三次元の複雑なモデルの方が良い ≪≫ 【そしてそれぞれのモデルの結果を対応付けるなどして考察を行います。この際に、 】 【図の真中の、「地球大気と火星大気との比較」、「現在と過去の気候の比較」を「階層的モデル群でアプローチ」しています。各モデルの話はする。効率的に「データがパッと見れる」とありがたいということだけ言う。めんどい話はしない。】 『このようなコストを気にするのは、我々の研究分野や研究スタイルに大きく関係しています。我々の研究グループでは、地球や火星の、現在そして過去の気候や気象に関して、様々なモデルによる実験や考察を行っています。』 『具体的には鉛直1次元モデル (左上)や南北1次元モデル (EBM)、そして2-3次元の雲解像モデル(右上)や全球を覆うような3次元球面モデル(左下)による実験を行っています。そして例えばGCM で出て来た結果を鉛直1次元モデルや南北1次元モデルと対応付けるなどの考察を行います。この「考察」の場合に、異なる研究者、または研究グループ間でのデータの相互参照が行われます。このような時、効率的に「データがパッと見れる」とありがたいのですが、現状では、そのデータがなんであるか、またデータを扱うためにどんなツールが必要かなどを教えあわなければなりません。当然、データの相互参照は頻繁に行われるので、一つ一つのコストはたいした事が無くとも、塵も積もれば山になるで、非常に大きなコストとなってしまいます。こういったことから、データの効率的な相互参照が行えることが切に望まれています。』 ・おはなし 『我々はこんな事をやってます。気候、気象、地球、火星、現在だけでなく、過去の状況、様々なモデルによる実験と考察。モデルによる実験とは鉛直1次元モデル (左上)、南北1次元モデル (EBM)、2-3次元の雲解像モデル(右上)、全球を覆うような3次元球面モデル(左下)。考察とはGCM で出て来た結果を鉛直1次元モデルや南北1次元モデルと対応付ける事。この「考察」の場合などに、データの相互参照が行われる。(できるだけ具体的に) 具体的に、効率的なのは、「データがパッと見れる事」具体的に非効率なのは、付加情報が必要になる上、環境を構築しなければならない。※ 自己記述的とかのさらに細部の話はここでは要らない』 『それぞれ違うモデルを使用して研究をしている研究者同士が互いのデータを見たい、使いたいときもあります。そのような場合に、常にデータのみならず、その内容、使うための手段を教えなければならないのは非常に面倒です。また、あらゆるデータを見るためにいろいろな環境をインストールしなければならない。ちなみに、これは我々の研究グループが行っている共同研究の概略図になります。このように我々にとってこのデータの効率的相互参照は重要です』 GCM、EBM、CRM (対流解像モデル)、 1D-RCM (1次元放射対流モデル)、観測データのそれぞれの比較が必要となる。それらによって生成されるデータが異なる形式の場合には、それぞれを扱うためのツール (環境) が必要となり、面倒である。それらを簡単に比較できるためには同様の形式のデータに書き出すことにし、同じツールを共有するのが便利である。 効率的なデータ相互参照が必要

4 目標：何が欲しいか？ 効率的な相互参照を可能にするもの 自己記述的データ構造 自由に利用できるソフトウェア データに関する情報がデータに付属
作成者・表題・履歴 etc... 変数・時刻・座標・欠損値・単位 etc... 自由に利用できるソフトウェア 公共財として利用できるもの 研究教育資源として提供 誰でも使用・改変・再配布が可能 『そういったデータ参照効率化のために、データ自身が自分の情報を一緒に持っている、そんなデータ構造を作りたいと考えています。これでデータさえあれば、そのデータの素性もわかるわけです。』 『また、データをやり取りする誰もがそのデータ構造を自分好みに扱う事ができるよう、誰でもが自由に使えるソフトウェアも必要です。僕は現在大学に籍を置いて研究していますが、例え大学を出ても、今までの研究成果をそのまま外でも使えるようになっていると嬉しいわけです。』 『で、このデータ構造とソフトウェアの2つを作ろうということで、』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 『【大学でも社会でも著作権に縛られない、大学で研究したことを外でも同じように使える。大学で勉強した事をそのまま外で使えるように…】主に大学での研究が中心となっていることもあり、誰でもが自由に利用できる、ソフトウェア』 『そういったわけで、効率的な相互参照が可能な、自己記述的、かつネットワーク透過的なデータ形式と、そのデータを使えるデータ I/O ライブラリ、解析・可視化ツール群を作ろうと考えています。』 『なお、これらは全て (さっきの話にあったとおり) オープン／フリーで地球科学に適したものにします』 『なお、僕らが使う上で便利なように、地球科学に適し、様々な場所で使えるものが良いと考えます。また、大学での研究が中心となっていることもあり、教育目的で誰でも自由に利用できるものにしたいとも考えます。』 『そういったわけで、これまでにお話しした要件を満たす、以下の4つのものを目標としています。』 『1つめ、2つめは特に効率的な相互参照と関わりますが、1つめはネットワーク上を透過的に持ち運べるようなファイル形式です。2つめはデータ自身の情報をデータ内に含むような自己記述的なデータ形式です。 3つめ、4つめは、そのデータを扱える、データI/Oライブラリと解析・可視化コマンド群で、様々なプラットフォームでの利用ができ、オープンでフリーなものであるようにと考えています。』 【上下のつながりをいくらかしゃべる】 『そういったわけで、このようなことを目標としています。』 『まず、データの氾濫を乗り切るために必要なものの要件として、効率的な相互参照が可能なもの。そして、オープン／フリーなもの、さらに地球科学に適したものの3つを考えています。』 『そして、具体的に、どういったものを作りたいかといいますと、1つは、機種などに依らず、どのようなプラットフォームでも利用できるような、透過的なファイル形式です。もう一つは、効率的な相互参照を可能にする、自己記述的なデータ形式です。そして、様々なプラットフォームで利用が可能なデータの入出力ライブラリと解析・可視化のツールセットです。』 ・お話 『いろんなところで使える』＝「様々なプラットフォームで利用できる」 背景 コンピュータの進歩とネットワークの成長により、科学者は巨大で多種多様な形式のデータをより効率的に扱う必要と直面している。 共通のデータ形式を作り、ソフトウェアを共有することで、それらの労力を軽減できる。 地球流体 (すなわち、大気、海洋、地球内部)を扱うデータのためのソフトウェア環境 “gtool” に関して報告する。 『これまでの取り組み』 = 『gt4f90io に先立つ取り組み』

5 gtool4 プロジェクト (1999～) 多次元 格子点 完全 自己記述 ネットワーク 透過 Fortran90 で実装 データ構造
ソフトウェア GTOOL3 【格子点データのライブラリ、解析・可視化ツール】 沼口 他(1989) 準自己記述 （座標は別ファイル） Unformatted バイナリ Fortran77 で実装 3次元格子点 次元制約の 不便性増大 座標用別ファイル 管理コスト増大 機種依存で コスト増大 Fortran90 登場 『（このデータ構造、そしてソフトウェアの開発プロジェクトとして） 』 『 gtool4プロジェクトっていうのをやってます。 』 『これは、10年ぐらい前に作ったGTOOL3 という格子点データの解析ツールの名を継いだものです』 『(利点)GTOOL3は、3次元格子点データの解析ツールです。研究する上で必要な情報をシーケンシャルファイルのヘッダに格納することで、当時としては画期的な自己記述的データ構造を実現していました。またそれを実装したソフトウェアもしっかりしており、結構優れたものでした。』 『しかし、時代の流れと共に、研究対象も多岐にわたり、3次元という制約にも不便を感じるようになってきました。』 『また、データの嵐に伴い流通量が増えた事で、今までなんとかかんとか管理していた座標用の別ファイルの管理が昔に比べて大変になってきました。』 『また、当時全てをスパコンで行っていた時に問題にならなかった、書式無しデータの機種依存性が、データをあちこちの計算機に持っていくようになり、足かせになってきました。』 『gtool4プロジェクトでは新たに、完全に自己記述で、ネットワーク上を簡単に持ち運べる、多次元格子点データ構造を策定するとともに、そのデータ構造を扱うソフトウェアを Fortran90 で開発しています。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ≪GTOOL3 が何かを一言でさらっと言う。利点もさくっといえるといいなぁ… （ぐっと良いとこを）≫ 『GTOOL3 は、Fortran77 にして結構良く出来ていたのですが、時代の推移、特に始めに説明したようなデータの嵐のような状況に押され、もう少し便利なツールが欲しいな、という要望が出てきました。GTOOL3 の基本的な性格は davis に近かったので、GTOOL3 の性格を受け継ぎつつ、今の時代にあった、新たなツールを開発しようという動きになりました。それが gtool4 プロジェクトと呼ばれるものです。』 『どうにかしたいてんは大きく 4 つありました。1つ目は、データとは別に、座標を定義する「軸ファイル」が必要だったため、完全に自己記述的では無かったことです。2 つめは、unformat なファイル形式であったため、浮動小数点や Big/Little endian による機種依存の問題を抱えていたことです。これはデータをスパコン内でのみ扱っていた昔にはあまり問題ではなかったのですが、PC の性能が飛躍的に増加し、簡単な計算や解析・可視化ができる今では面倒な問題となってしまいました。3 つ目は、データ構造として、3 次元までに制限されていたことです。時間の次元は、Sequential データ1 レコード を時間 1 ステップとして含めてたんですが、結局、例えば平均操作の際に、空間と別の処理が必要で面倒でした。4 つめは、開発者側の利点ですが、プログラムの内部構造がかなり複雑であったことです。』 ・欠点だけを上げる形に (gtool4 での具体的な対策は述べない) ・始めに対応する事だけ言って、あとは欠点を羅列 『GTOOL3 は結構良く出来ていたのですが、まだいくつかの大きな欠点を持っていました。それらを克服したデータ形式およびツールセットの開発を目指して gtool4 プロジェクトというものを開始しました。』 『GTOOL3 の欠点は大きく 4 つありました。1つは軸ファイルの存在です。軸ファイルはデータには必ず必要であったため、完全な自己記述的データとは言い切れませんでした。Gtool4 ではデータと「軸ファイル」も統合した、完全な自己記述的データを目指す事となりました。GTOOL3 の2 つめの欠点はデータの可搬性で、unformat なファイル形式であったため、浮動小数点や Big/Little endian による機種依存の問題を抱えていました。Gtool4 ではこれらの問題の回避を目標の1つにしています。3 つ目の欠点は、データの次元が 3 次元までに制限されていたことです。主に、時間の次元が特別扱いで、操作の際にも空間と別の処理が必要でした。Gtool4 では、時間の操作も空間と同様にして行えるよう、多次元データを扱えるデータ形式にできるよう考えています。4 つめは、プログラムの内部構造がかなり複雑であったことです。Gtool4 では内部構造の徹底的な階層化を目指しています。』 ・お話 『GTOOL3 の欠点をしゃべる』 『それで、実は先ほどの GTOOL3 はソフトウェアとしてもかなり完成していました。…がそれでもいくつか使い勝手が悪い部分があり、それを克服した新たなツールセットと開発を目指したのが gtool4 です。主に重点を置いたのが以下の 4 点で…。… 4 つ目は可読性で、内部のサブルーチンと役割を統一するなど、メンテナンス効率化を目的としています。これは開発者にとっての目的ともいますが、広い意味ではユーザの利点ともいえます。』 ・gtool4 プロジェクトの開始は 1999 年 ・『可読性』に関して f77 の問題(?)点となるわけだが、Fortran77 では、サブルーチンや変数を 6 文字でしか書けないため非常に読むのが大変. ・『拡張性』に関して 少なくとも、現在 gt4_history に関しては空間 3 次元 + 時間 1 次元のデータを出力するようにしかなっていないので、 「多次元」と言い切れるのか微妙 多次元 格子点 完全 自己記述 ネットワーク 透過 Fortran90 で実装 gtool4 【データ構造策定 ＆ ソフトウェア開発プロジェクト】 豊田 他 (2000)

6 gtool4 Fortran90 Tools/Library
データ構造 『gtool4 netCDF 規約』 多次元格子点データ 完全自己記述的 座標軸情報もデータに含まれる ネットワーク透過 COARDS 規約、NCAR CSM 規約 との互換性を考慮 ソフトウェア 『gtool4 Fortran90 Tools/Library』 Fortran 90 ： モジュール、構造型、総称手続き を活用 『これまでに、データ構造としてgtool4 netCDF規約を、ソフトウェアとして gtool4 Tools/Library を作りました。』 『gtool4 netCDF規約とは、多次元データを自己記述的に格納するデータ構造のための約束事です。ファイル形式として netCDF を用いているのでネットワーク透過でもあります。主に地球を始めとする惑星の流体現象の研究に必要なものを自己記述情報として格納します。』 『既に業界でもNOAA (National Oceanic and Atmospheric Administoration)の COARDS (Cooperative Ocean/Atmosphere Research Data Service) 規約や NCAR (National Center for Atmospheric Research)のCSM (Climate System Model)規約といったnetCDF 規約が存在しています。Gtool4 netCDF 規約はこれらとの互換性も考慮しています。』 『ソフトウェア gtool4 Fortran90 Tools/Library はこの gtool4 netCDF データを書き出すI/Oライブラリとそれを解析するツールから成ります。Fortran90 の新しい機能を生かし、実装しています。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー （ボツ）『netCDF とは、多次元配列を格納できるデータ形式で、ファイルや変数に属性情報を付加する事が出来、さらにネットワーク上を透過的に持ち運べるファイル形式です。』 『そして規約とは、データに付け加える付加情報』 〔＊＊＊『Unidata( Common Data Form (NetCDF)ソフトウェアは、本来、数あるUnidataのアプリケーション用に共通のデータアクセス方法を提供する目的で開発されました。これらは定点観測・時系列・等間隔格子・衛星やレーダー観測等の様々なデータの種類を網羅しています。』＊＊＊〕 『そして、新たなツールセットとして、 gtool4 Tools/Library を開発、そしてデータ形式として、gtool4 netCDF 規約を策定してきました。これは、主に、当時北大にいらっしゃった豊田さんによって手がけられたものです。現在は気象庁の数値予報科にいらっしゃいますが』 『gtool4 Tools/Libraryもまた、 I/Oライブラリと解析・可視化のコマンド群を含むツールセットです。しかし、言語として Fortran77 に代わり、Fortran90 を用います。ファイル形式として Fortran 形式に代わり、netCDF を用います。Fortran90 の新たな機能によって、内部構造の階層化の実現を目指します。netCDFを用いる事で機種非依存と多次元データの扱いを実現します。』 『なお、今のところはファイル形式として netCDF だけを想定していますが、他のデータ形式とのアクセスも考えた設計を目指しています。』 『そして、自己記述的データ形式の実現のために、gtool4 netCDF 規約の策定も行っています。 規約とはメタデータ (データのためのデータ) および数値データに関する約束事で、既に業界では、NOAA (National Oceanic and Atmospheric Administoration)の COARDS (Cooperative Ocean/Atmosphere Research Data Service) 規約や NCAR (National Center for Atmospheric Research)のCSM (Climate System Model)規約で netCDF に関する規約が存在しています。それらとの互換性を考慮しつつ、我々でも、地球科学の格子点データを想定した規約を策定しています。 (PCMDI(Program for Climate Model Diagnosis and Intercomparison)の GDT(Gregory, Drach, Tett)規約に関しては色々な理由で互換性に関して言及できず)』 『一昨年あたりまではこのように、gtool4 プロジェクトとしてI/Oと解析・可視化ツールセット、そして規約との2本を軸に開発を行ってきました。』 (以下は小高さんのコメント) 『そして、自己記述的データ形式の実現のために、gtool4 netCDF 規約の策定も行っています。 規約とはメタデータ (データのデータ) および数値データに関する約束事で、既に業界では、COARDSやGDTで netCDF に関する規約が存在しています。それらを参考にしつつ、我々でも、地球科学の格子点データを想定した規約を策定しています。』 ・お話 『Fortran90 と NetCDF により GTOOL3 の欠点を克服する事を強調』 『これまでに gtool4 Tools/Library の… 。… 構成は今までと基本的に変わりませんが、NetCDF 形式を考えたために NetCDF 用のライブラリを使用していることと、今はまだ未定ですが、他のデータ形式とのアクセスも考えた設計を目指しています。そしてもう一つ、gtool4 netCDF 規約の策定も行っています。 規約とはメタデータ (データのデータ) および数値データに関する約束事です。す既にいろいろな netCDF に関する規約が存在します。netCDF 形式は多次元データの格納と自己記述的にファイル自体と変数に情報を与える事ができるということしか決まっていません。よって、どのような情報をファイルに与えるかは利用者側が目的に合わせて決めなければいけません。そういった訳で、地球流体現象を念頭に置いた格子点データを想定した、規約を策定し、研究グループ内で相互参照を容易にできるようになるような取り決めを作った。他の研究者にデータだけ渡せば済むような取り決めを作ったわけです。』 ・『構造 (データ) 型』 = 『derived data type』 ・『総称手続き : generic procedure』を一言で言えば、interface である。 つまり、F90 のコードで書くと interface [総称名称] [個別引用仕様宣言] <= function や subroutine を書く [module procedure 手続き名並び] <= モジュール化されたもののサブルーチン名だけ書く end interface gtool4 Fortran90 Tools/Library 数値モデル データ I/O ライブラリ 解析・可視化 ツール 解析・可視化 gtool4 netCDF データ

7 gtool4 の、今 データ構造 『gtool4 netCDF 規約』 ソフトウェア 試用中 ＆ 策定中 解析・可視化ツール
オブジェクト指向言語 Ruby へ データ I/O ライブラリ データ I/O ライブラリとして特化した gt4f90io へ 『…で現在は、データ構造は使ってみたり作ってみたり繰り返しているところです』 『ソフトウェアですが、近年の計算機環境の推移に伴い、解析・可視化ツールに関しては、オブジェクト指向のスクリプト言語である Ruby を用いて作る事にしました。 既に電脳rubyプロジェクトというプロジェクトでそのためのツールを作成しつつあります。』 『一方、I/Oライブラリはどうするかというと、僕らは数値モデルを Fortran90 で書いていることから、Fortran90 での開発を続ける事としました。 解析・可視化部分を取り外す事となったので、名前を gt4f90io と変え、I/Oとしての機能に特化したソフトウェアとして再パッケージすることとしました。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 『データ構造の作成に関しては、今までどおり gtool4 netCDF規約を充実させていくことにしてます。まだまだ不足している属性とかもありそうですし。他のメジャーな規約を横目で眺めつつ、策定を継続しています。 』 『で、この gt4f90io が僕の直接手がけているツールです。話術を心得ていないので絵で強引に注目を引こうとしてますが。』 『しかし、近年の計算機環境の推移もあって、解析・可視化ツールに関しては、オブジェクト指向のスクリプト言語である Ruby を用いて作る。 正にこのワークショップを主催してます、電脳rubyプロジェクト (2003) でそのためのツールがちゃくちゃくと作成されあります。』 ・お話 『2本立てを3本立てにしました』 『…。(解析では数値計算するので注意。でもそれ以上にメリットがあることを述べる。メリットは文字処理や配列処理、機能が豊富でプログラムが楽)。データ I/0 ライブラリに関しては、数値モデルが F90 で書かれる事が大半なので、それとの親和性を考えると fortran90 によってあった方が便利であろう、ということで f90 での開発を続ける事になりました。 gtool4 netCDF 規約以外にも netCDF 規約はあるのですが、あまり他のメジャーな規約と外れてしまわないように他の規約を横目で眺めつつ、策定を継続しています。 』 開発を進めるにつれて… 解析、描画のためには Fortran 90を用いるよりもオブジェクト指向スクリプト言語を用いる方が向いていることが分かった 具体例： Dennou Ruby Project ツール … ・Gtool4 NetCDF Conventions は地球流体現象を念頭においた格子点データのための自己記述的表現方法です。 ・ 現存のConventions との互換性に関して書くと冗長かな? 豊田さんの発表資料の「Compatibility to Existing Conventions」を参照のこと gt4f90io 電脳 Ruby 数値モデル データ I/O ライブラリ 解析・可視化 ツール 解析・可視化 gtool4 netCDF データ

8 gt4f90io gtool4 netCDF データの I/O ライブラリ Fortran90 ベースの数値モデル用 正式名称
[日] gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ [英] Fortran90 netCDF I/O library with gtool4 convention 『こういった経緯を経て、gtool4プロジェクトの一環として、gtool4 netCDFデータのI/Oライブラリgt4f90ioを作りました。』 『Fortran90 の数値モデルから、簡単に gtool4 netCDF データを書き出せるように、機能を特化させたツールといえます。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 『ライブラリの利用者にとって使いやすいものにするため、手軽に使えるインターフェースを提供するようにしています。直接 netCDF のライブラリを呼ぶのは。。。Gtool4 netCDF 規約で定められた必要な情報は全てそのインターフェースを通して自動的に書き出されるようにしています。』 『自己記述的に与えるデータが増えた分だけ、その付属データを扱う手間は普通増えてしまいますが、このライブラリではそういった手間をできるだけ減らせるように、付属データを自動で扱えるようになっています。』 gt4f90io 数値モデル データ I/O ライブラリ gtool4 netCDF データ

9 内部構造階層化 モジュール構造概観 gt4f90io gtool4 netCDF データ 数値モデル （Fortran90）
gt4_history 数値モデルの結果を gtool4 netCDF 形式の多次元数値 データとして出力するための Fortran 90 インターフェース 文字列と数値の変換など 内部用汎用ライブラリ dc_string gtdata_generic 各種のデータ形式を抽象化した多次元数値データ アクセスライブラリ (データ形式の違いは下層のライブラリによって吸収) dc_trace dc_error デバッグ用モジュール エラーの処理 ??_generic その他の形式の データアクセス用 下層ライブラリ （未定） 『このgt4f90io、利用者にとって使いやすいようするのはもちろんとして、内部構造の階層化にもちょっと凝ってます。』 『この点線で囲まれた部分が gt4f90io です。上のこれが数値モデルで、下のこれが gtool4 netcdf データです。』 『gt4f90io の内部はその役割に応じて大きく3 つに階層化されています。まず一番下にあるのが netCDF データ用のライブラリで直接は gtool4 netCDF データを読み書きするのはこの部分です。真中のが抽象化した多次元数値データを取り扱う本体部分です。そして、上にあるのが数値モデルから直接用いるユーザインターフェースです。実際には 100 を超える Fortran90 プログラムがありますが、Fortran90 のモジュール機能を用いて、明確な階層化を行っています。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 『こちらが内部構造の概略図です。』 【下から丁寧に説明する】 （旧）『先ほど、gtool4 プロジェクトの目的として、内部構造の階層化を上げました。実際に、内部はその役割に応じて3 つに階層化されています。まず一番下にあるのが netCDF データ用のライブラリ、真中のが数値データを取り扱う本体部分です。そして、上にあるのがユーザインターフェースです。実際には 100 を超える Fortran90 プログラムがありますが、Fortran90 のモジュール機能を用いて、明確な階層化を行っています。』 『数値モデルから直接呼ぶのがさきほどの gt4_history です。次が数値データを扱う本体部分、その下が netCDF データとアクセスするためのライブラリです。直接はここから gtool4 netCDF データを読み書きします。』 『下層のモジュールが netCDF ライブラリが直接を呼んでいます』 『情報隠蔽が可能になっています。』 『実際には 100 を超える Fortran90 プログラムがありますが、Fortran90 のモジュール機能を用いることで、明確な階層化が可能になっています。 』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 『この点線で囲まれた部分が gt4f90io です。上のこれが数値モデルで、下のこれが netCDF ライブラリなどです。』 『先ほど、gtool4 プロジェクトの目的として、内部構造の階層化を上げました。実際に、内部はその役割に応じて3 つに階層化されています。まず一番下にあるのが netCDF データ用のライブラリ、真中のが数値データを取り扱う本体部分です。そして、上にあるのがユーザインターフェースです。実際には 100 を超える Fortran90 プログラムがありますが、Fortran90 のモジュール機能を用いて、明確な階層化を行っています。』 ・お話 『3 つに階層化されています。まず下にあるのが netCDF データ用のライブラリ、真中のが数値データを取り扱う本体部分です。そして、上にあるのがユーザインターフェースです。実際には 100 を超える Fortran90 プログラムがあるが、Fortran90 のモジュール機能を用いて、階層化をうまく行っていることです。 』 『3 つに階層化されています。まず netCDF データアクセス用の下層ライブラリ、netCDF のデータ形式を扱う、ということに関してはこのライブラリで閉じています。そして抽象化された多次元数値データを扱う中層のライブラリです。そして、これはユーザインターフェースとなる上層ライブラリです。後は内部の様々なところで使うような汎用のライブラリがまとめられたライブラリがあります。あと、sysdep…。で、例えば他の形式のデータアクセスを…実際には 100 を超える Fortran90 プログラムがあるが、Fortran90 のモジュール機能を用いて、階層化をうまく行っていることです。 』 ・ 、役割としては上記のように統一されている。 ・ 全部で 行、 バイト ・『API』 = 『Application Program Interface』 ・『Specialized』＝「限定される」 ・『Subarray』＝『』 an_generic sysdep netCDF データアクセス用下層ライブラリ。 netCDF 変数の入出力ファイルのオープン、 入出力範囲の保持、属性の文字列変換など Fortran コンパイラに 依存するコードの共通 インターフェイスを提供 その他のデータ (未定) gtool4 netCDF データ

10 ライブラリ利用者は を知っていれば OK お手軽インターフェース モジュール gt4_history サブルーチン 5 つ
サブルーチン つ を知っていれば OK 『この階層化の結果、情報隠蔽などが可能になり、ライブラリの利用者は非常に手軽に使えるインターフェースを利用できるようになりました。』 『まず、ライブラリの利用者用のお手軽インターフェースとして、gt4_history というモジュールを用意しました。このモジュール内の 5 つのサブルーチンだけ知っていれば OK です。（もちろん、netCDF の生みの親であるUnidata から提供されている本家のnetCDFライブラリを使えば gtool4 netCDF データの出力を可能は可能ですが、数多い引数をもつ数多くのサブルーチンを、netCDF のマニュアルと 規約とを見比べながらコーディングせねばならず、かなり面倒です）』

11 gt4_history のサブルーチン 違うデータ型も 同サブルーチンで対応 HistoryCreate(file, title, …)
初期設定 出力ファイル名、タイトル、…、次元変数名、次元サイズ、… HistoryAddVariable(varname, dims, …) 変数定義 変数名、依存次元名、… HistoryPut(varname, value, …) 変数出力 変数名、出力値、… HistoryClose 終了処理 HistoryGet(file, varname, …) 変数入力 ファイル名、変数名、… 『これが５つのサブルーチンです』 『HistoryCreate で出力するファイル名や次元を設定します。そして出力したい変数、例えば風速や温度などといったものですが、それらを HistoryAddVariable というサブルーチンで設定します。後、HistoryPut サブルーチンでデータを出力し、最後に終了宣言として HistoryClose というものがあります。』 『既にある gtool4 netCDF データからデータを入力する場合はこの HistoryGet を使います。』 『特徴として、Fortran90 の総称手続きで、違うデータ型であっても、同じサブルーチンで対応が可能です。』 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 【具体的な使い方は次のページで話す】 『この 4 つのサブルーチンです。』 『まず、初期設定として、HistoryCreate というサブルーチンを利用します。ここで、出力するファイル名やタイトル、系の次元やその次元サイズなどを設定します。そして出力したい変数、例えば風速や温度などといったものですが、それらを HistoryAddVariable というサブルーチンで設定します。設定自体はこれで終了です。後は、時間積分の do ループ文中などに HistoryPut サブルーチンを用いてデータを出力し、最後に HistoryClose で終了宣言するだけです。』 『特徴としては、Fortran90 による総称手続き (generic Procedure) によって、違うデータ型のデータであっても、同じ名前のサブルーチンを用いる事ができることにあります。例えば、HistoryPut でデータを出力する際、普通は単精度と倍精度の違いだけで、異なる名前のサブルーチンを用意する必要がありますが、ここではその必要はありません。』 『総称名称』 違うデータ型も 同サブルーチンで対応

12 使用例 サンプル Fortran 90 プログラム program sample use gt4_history ! モジュールの使用を宣言
[型宣言] call HistoryCreate( & ! ヒストリー作成 file='sample.nc', title='gt4_history', & ! ・ファイル名、タイトル ..., dims=(/'x','t'/), dimsizes=(/30,0/), & ! ・次元変数、次元サイズ ) call HistoryAddVariable( & ! 変数定義 varname='temp', dims=(/'x','t'/), .... ) ! ・変数名、依存次元、.. [時間積分ループ] : call HistoryPut(varname= 'temp', value=temp) ! 変数の出力 [時間積分ループ 終わり] call HistoryClose ! 終了の処理 stop end program sample 『非常に簡単なコーディングの具体例です。』 『まず、始めに gt4_history モジュールを呼び、型宣言の後に、HistoryCreate、HistoryAddVariable でファイル名やタイトルや次元や変数を設定し、時間積分の do ループ文中で HistoryPut を呼び、プログラム終了の前に HistoryClose を呼び出します。』

13 まとめ データ I/O ライブラリ gt4f90io 課題 導入例 Fortran90 ベースの数値モデル用
gtool4 netCDF 規約に基づくデータを扱う 課題 gtool4 netCDF 規約へ完全に対応 入力用サブルーチン HistoryGet 改良 データサイズに応じて出力データを自動分割 導入例 SPMODEL (Hierarchical Spectral Models for GFD) 階層的地球流体力学スペクトルモデル集 コードの可読性を重視 データ I/O に gt4f90io を使用 『…というわけで、データ構造とそのソフトウェア開発を目指すgtool4 プロジェクトの一環として、データI/Oライブラリ gt4f90io を作りました。この I/O ライブラリによって、Fortran90の数値モデルから gtool4 netCDF データを簡単に扱う事ができるようになりました。』 『さらにこれを電脳 Ruby のツールで解析・可視化でき、非常に便利です。』 『今後の課題として、』 『gtool4 netCDF規約もこれから変化していくので、利用者が分かりやすいように、gt4f90io が対応している属性情報のリストを作っておきたいと考えています。』 『また、実は出来たての入力サブルーチンを改良したり、サイズに応じて出力データを自動的に分割してくれるようにもしたいと考えています。』 『なお、gt4f90io は既に数値モデル群に導入されています。その一例として、SPMODEL があります。これは地球流体力学のスペクトルモデルを階層的に整備したもので、コードの可読性を重視し、数式のようなコードが簡単に書けることを目指しています。SPMODELでは gt4f90io を用いることで、本家のnetCDF ライブラリを直接用いるのに比べはるかに簡単に gtool4 netCDF データを入出力できています。SPMODEL に関する詳しい話は次の発表をお聞きください。 』

14 参考 URL gt4f90io （gtool4 プロジェクト） http://www.gfd-dennou.org/arch/gtool4
電脳 Ruby プロジェクト SPMODEL 『なお、今回紹介した gtool4 プロジェクトやその成果物である gt4f90io に関してはこの URL を参照ください。』 『ここまでで発表はおしまいです。何か御質問などありますでしょうか？』

15 メモ

16 以降、付録(?)

17 gt4f90io 詳細図

18 gtool4 Tools/Library 詳細図

19 おまけ（お手軽 Install） debian パッケージあります 使い方はチュートリアル参照してね
/etc/apt/sources.list に以下の 4 行を追加 apt でインストール これはFujitsu Fortran 4 用。 他にも ffc3 や Intel Fortran コンパイラ、ifc6, ifc7, ifc8 を用意 使い方はチュートリアル参照してね deb ftp:// woody/ deb-src ftp:// woody/ deb ftp:// woody/ deb-src ftp:// woody/ # apt-get install gt4f90io-ffc4 netcdf-ffc4 ちなみに、debian を使っている人には deb パッケージが用意されてます。よろしければお試しください。一応チュートリアルもあります。

20 総称手続き Fortran 90 コーディングスタイル 上位モジュール 下位モジュール オブジェクト指向“的”に…
クラス → 構造型 メソッド → サブルーチン 多態性 (polymorphism) → 総称宣言されたサブルーチン 引数の型に合わせ、異なるサブルーチンが呼び出される (下図参照) 上位モジュール 《引数の型を気にせず、サブルーチンを呼び出せる》 ・『動的多相性：dynamic polymorphism 』に関して 動的多相性→ スーパークラスをサブクラス構造型へのポインタ群をまとめた構造型とすることで実現 ※ 具体的に用いられているのは GT_OBJECT などの可視化部分のようで、 I/O 部分はそのようなポインタの用いていないようだ。 ・『derived data type』＝『構造型』 ・『Object-oriented module』 = 『オブジェクト指向モジュール』 ・『polymorphism』 =『ポリモルフィズム ： 動的結合』=『動的多相性???』 ・『カプセル化』= 『情報隠蔽』 ・「ポリモルフィズム」は分かったけど、「static」や「dynamic」が分からない… ・『総称手続き : generic procedure』を一言で言えば、interface である。 つまり、F90 のコードで書くと interface [総称名称] [個別引用仕様宣言] <= function や subroutine を書く [module procedure 手続き名並び] <= モジュール化されたもののサブルーチン名だけ書く end interface 総称名称 （例：HistoryAddAttr） 《引数の型に応じて実際に 呼び出されるサブルーチンが変化》 個別の サブルーチン 文字型用 論理型用 実数型用 例：HistoryAddAttrC 例：HistoryAddAttrL 例：HistoryAddAttrR 例：Histo.. 下位モジュール

21 gt4_history 具体的使用例 サンプル Fortran 90 プログラム program sample
use gt4_history ! モジュールの使用を宣言 [型宣言] .. call HistoryCreate( & ! ヒストリー作成 file='sample.nc', title='gt4_history sample', & ! ・ファイル名の指定、データ全体の表題の指定 source='Sample program of gt4_history/gt4f90io', & ! ・データを生成する手段 institution='GFD_Dennou Club davis project', & ! ・ファイルを最終的に変更した人/組織 dims=(/'x','t'/), dimsizes=(/30,0/), & ! ・次元変数、次元のサイズの指定 longnames=(/'X-coordinate','time '/), & ! ・次元の名前 units=(/'m','s'/), & ! ・次元の単位の指定 origin=real(0.0), interval=real(0.005) ) ! ・時間の原点、出力時間間隔の指定 call HistoryPut('x',x) ! 変数の出力 call HistoryAddAttr('x', 'topology', 'circular') ! 変数に属性を追加 call HistoryAddVariable( & ! 変数定義 (属性指定) varname='temp', dims=(/'x','t'/), & ! ・変数名、依存する次元の指定 longname='temperature', units='K', xtype='double') ! ・変数の(長い)名前、単位、変数の型の指定 [時間積分ループ] : call HistoryPut('t',real(it*dt)) ! 変数の出力 call HistoryPut('temp',temp) ! 変数の出力 [時間積分ループ 終わり] call HistoryClose ! 終了の処理 stop end program sample

22 gt4_history 使用結果 by gtool4 netCDF 規約に則った netCDF ファイル 解析 and 可視化
$ ncdump sample.nc (netCDF ファイルの属性 + データを出力) [出力結果] dimensions: x = 30 ; t = UNLIMITED ; // (201 currently) variables: float x(x) ; x:long_name = "X-coordinate" ; x:units = "m" ; x:topology = "circular"; float t(t) ; t:long_name = "time" ; t:units = "s" ; double temp(t, x) ; temp:long_name = "temperature" ; temp:units = "K" ; // global attributes: :title = "gt4_history sample" ; :source = "Sample program of gt4_history/gt4f90io" ; :institution = "GFD_Dennou Club davis project" ; :history = "unknown unknown> gt4_history: HistoryCreate\n", "" ; data: x = 0, , , , , , , : t = 0, , 0.001, , 0.002, , 0.003, , 0.004, , temp = e-11, e-10, e-09, 解析 and 可視化 by RubyNetCDF + RubyDCL + Gphys + … topology = "circular" ;