gt4f90io: gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ ○ 森川 靖大 (北大・理・地球惑星) [morikawa@ep.sci.hokudai.ac.jp] 小高 正嗣 (北大・理・地球惑星) [odakker@gfd-dennou.org] 石渡 正樹 (北大・地球環境) [momoko@ees.hokudai.ac.jp] 林 祥介 (北大・理・地球惑星) [shosuke@gfd-dennou.org] 『北海道大学の森川です。このたびは、gt4f90io というFortran90 のライブラリに関してお話させていただきます。』

目標 階層化モデルの データ I/O ライブラリ 要件 ネットワーク透過的なファイル形式 自己記述的なデータ形式 いろいろなところで利用可能 『先ほどの小高さんのお話で「階層的モデル群の間での比較」という話がありました。この gt4f90io というのは、その階層的なモデル群で使うのに適したデータI/Oライブラリを目指したツールです。』 『で、その目的に適したライブラリとして、ネットワーク透過的なファイル形式、自己記述的なデータ形式を扱え、また様々なプラットフォームで使えることが必要になります。これらは、先の話にもあった、効率的な相互参照につながっています。』 『そういったわけで、これまでにお話しした要件を満たす、以下の4つのものを目標としています。』 『1つめ、2つめは特に効率的な相互参照と関わりますが、1つめはネットワーク上を透過的に持ち運べるようなファイル形式です。2つめはデータ自身の情報をデータ内に含むような自己記述的なデータ形式です。 3つめ、4つめは、そのデータを扱える、データI/Oライブラリと解析・可視化コマンド群で、様々なプラットフォームでの利用ができ、オープンでフリーなものであるようにと考えています。』 【上下のつながりをいくらかしゃべる】 『そういったわけで、このようなことを目標としています。』 『まず、データの氾濫を乗り切るために必要なものの要件として、効率的な相互参照が可能なもの。そして、オープン／フリーなもの、さらに地球科学に適したものの3つを考えています。』 『そして、具体的に、どういったものを作りたいかといいますと、1つは、機種などに依らず、どのようなプラットフォームでも利用できるような、透過的なファイル形式です。もう一つは、効率的な相互参照を可能にする、自己記述的なデータ形式です。そして、様々なプラットフォームで利用が可能なデータの入出力ライブラリと解析・可視化のツールセットです。』 ・お話 『いろんなところで使える』＝「様々なプラットフォームで利用できる」 背景 コンピュータの進歩とネットワークの成長により、科学者は巨大で多種多様な形式のデータをより効率的に扱う必要と直面している。 共通のデータ形式を作り、ソフトウェアを共有することで、それらの労力を軽減できる。 地球流体 (すなわち、大気、海洋、地球内部)を扱うデータのためのソフトウェア環境 “gtool” に関して報告する。 『これまでの取り組み』 = 『gt4f90io に先立つ取り組み』

GTOOL3 (1989) GTOOL3 ソフトウェア GTOOL3 データ構造 I/O ライブラリ + 解析・可視化コマンド群 Fortran77 で記述 構成 GTOOL3 Library 数値モデル I/O ライブラリ 解析コマンド群 可視化コマンド群 DCL Library 文字処理、数値基礎処理、 可視化ライブラリ 『まずgt4f90ioより先に、そのルーツとなるソフトウェアを 2 つ紹介します』 『最初に取り組んだのがこの GTOOL3 です (1989～1990)。作者は当時？？？？にいらした沼口さんです。AGCM5の？？？でもあります。この GTOOL3 は、数値モデルのI/Oとして使えるライブラリと解析・可視化のコマンド群を含むツールセットでした。当時は、I/Oライブラリだけではなく、それによって入出力されるデータを解析・可視化するツールも含んでいました。解析・可視化部分は、右下の DCL Libraryという、文字処理、数値基礎処理、可視化のライブラリを用いています。なお、言語はFortran77 を用いています。』 『データ形式としては Fortran sequential unformatted ファイルを採用しています。これはヘッダ部分にデータ名や次元サイズ、作成日などの情報を格納する事ができていまして、自己記述性をある程度実現できています。』 ・お話 『今までにも、要件を満たすような、いろいろなソフトウェアの開発を行ってきました。最初に取り組んだのがこの GTOOL3 です。この GTOOL3 とは…で、右下に DCL Library というのは我々の共同研究グループである地球流体電脳倶楽部の共同研究者が開発した文字処理、数値基礎処理、可視化のライブラリで、GTOOL3 はこの DCL Library の可視化機能をライブラリとして用いています。データ形式としては…。時間に関しては、sequential なので、一度に書き出す 1 レコード 1 レコードを時間の 1 ステップと扱うようにしています。』 ・GTOOL3 は 1995 年のもの ・『Fortran sequential unformatted ファイル』 - 磁気テープに保存する事を想定 - 1 レコードごとに「ヘッダ」部と「データ」部があり、ヘッダ部にデータの情報が格納されている。（実は、ある程度描画情報も含まれている。） ・ 時間に関しては、 1 レコード 1 レコードを1 時間ステップとして取扱っている. ※ 1 レコード -- Fortran では, 1 度で書き出したものを「レコード」と呼ぶ. つまり, あるプログラム等で3 回書き出しを行ったのならば, それには 3 レコード分あるということである. GTOOL3 データ構造 Fortran sequential unformatted ファイル 自己記述性を (ある程度) 実現 ヘッダ部分にデータ名や次元サイズや作成日などの情報を格納

gtool4 プロジェクト (1999) GTOOL3 の欠点を克服 自己記述性の強化 ネットワーク透過性の向上 データ構造の多様性への対応 データと「軸ファイル」を統合 ネットワーク透過性の向上 機種依存 （浮動小数点、Big/Little endian問題） 回避 データ構造の多様性への対応 3 次元以上のデータの取り扱い 内部構造の整理 徹底した階層化 『GTOOL3 は Fortran77 にしては結構良く出来ていたのですが、大きく 4 つの欠点を持っていました。』 『1つ目は、データとは別に、座標を定義する「軸ファイル」が必ず必要でした。そのため、完全に自己記述的では無かったんですね。2 つめは、unformat なファイル形式であったため、浮動小数点や Big/Little endian による機種依存の問題を抱えていたことです。これはネットワーク透過性を随分低下させていました。3 つ目は、データ構造として、3 次元までに制限されていたことです。時間の次元は、Fortranデータ1 レコード を時間 1 ステップとして含めてたんですが、結局、例えば平均操作の際に、空間と別の処理が必要で面倒でした。4 つめは、開発者側の利点ですが、プログラムの内部構造がかなり複雑であったことです。』 『それらを克服したデータ形式およびツールセットの開発を目指して gtool4 プロジェクト(1999) が始めました』 ・欠点だけを上げる形に (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 次元のデータを出力するようにしかなっていないので、 「多次元」と言い切れるのか微妙

gtool4 Fortran90 Tools/Library 今までの取組み gtool4 Tools/Library I/O ライブラリ + 解析・可視化コマンド群 Fortran 90 で記述 ： モジュール、構造型、総称手続き を活用 ファイル形式は netCDF ： 高移植性、多次元データ、自己記述的 構成 gtool4 Fortran90 Tools/Library 数値モデル I/O ライブラリ 解析コマンド群 可視化コマンド群 NetCDF Library その他のデータアクセス ライブラリ (未定) DCL Library 『このような欠点を克服したツールセットとして、この gtool4 Tools/Library を、そしてデータ形式として、gtool4 netCDF 規約を策定してきました。これは、現在気象庁にいらっしゃる豊田さんによって手がけられたものです』 『gtool4 Tools/Libraryもまた、 I/Oライブラリと解析・可視化のコマンド群を含むツールセットです。しかし、言語として Fortran77 に代わり、Fortran90 を用います。ファイル形式として Fortran 形式に代わり、netCDF を用います。Fortran90 の新たな機能によって、内部構造の階層化の実現を目指します。netCDFを用いる事で機種非依存と多次元データの扱いを実現します。』 『なお、今のところはファイル形式として netCDF だけを想定していますが、他のデータ形式とのアクセスも考えた設計を目指しています。』 『データの形式は、自己記述的データ形式を目指し、gtool4 netCDF 規約の策定を行っています。 これに関しては小高さんのお話で詳しく紹介されたので、ここでは割愛します』 『このように、これまではtools/libraryと規約との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 netCDF 規約 多次元数値データとその可視化情報を自己記述的に格納するための netCDF 規約 地球科学の格子点データを想定

現在の取り組み 解析、可視化コマンド群 データ I/O ライブラリ gt4f90io として単独での再パッケージング オブジェクト指向スクリプト言語 Ruby へ Dennou Ruby Project データ I/O ライブラリ gt4f90io として単独での再パッケージング gtool4 netCDF 規約 引き続き策定を継続 『…とこのように考えていたのですが、最近の計算機環境の発達もあって、解析ツールや可視化のツールに関してはオブジェクト指向のスクリプト言語である Ruby で作った方が楽でいいものができるようだったので、gtool4 プロジェクト自身で、Fortran で書くのは止めようかということになりました。 現在、正にこのワークショップを主催してます、電脳rubyプロジェクト (2003) でそのためのツールがちゃくちゃくと作成されありますので、そちらに依存しようか、という方針になっています。』 『データ I/0 ライブラリは、Fortran90 での開発を続ける事としました。数値モデルが Fortran90 で書かれる事が大半なため、Fortran90 の I/O ライブラリの方が親和性に優れるというのがその理由です。ツールセットとしては、解析・可視化部分を取り外す事となったので、名前を 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」を参照のこと

gtool4 Fortran90 Tools/Library gt4f90io [Fortran90 netCDF I/O library] 数値モデルの データ I/O ライブラリ として特化 正式名称 [日] gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ [英] Fortran90 netCDF I/O library with gtool4 convention 構成 gtool4 Fortran90 Tools/Library gt4f90io [Fortran90 netCDF I/O library] 『ではやっと、メインのgt4f90io のお話です。』 『gtool4 Fortran90 Tools/Library は、このような構成をしていました。ここから解析・可視化部分をとりはずしたものが gt4f90io です。同時に可視化ライブラリとして依存していた DCL Library への依存も消滅します。 この目的は、I/Oライブラリへの特化です。』 ・お話 『構成を見せる』→ 『目的』 →『名前』 数値モデル 解析コマンド群 可視化コマンド群 I/O ライブラリ NetCDF Library その他のデータアクセス ライブラリ (未定) DCL Library

gt4f90io – Fortran90 netCDF I/O Library UNIDATA netCDF Library モジュール構造概観 数値モデル (Fortran 90で記述) gt4f90io – Fortran90 netCDF I/O Library gt4_history 数値モデルの結果を gtool4 netCDF 形式の多次元数値 データとして出力するための Fortran 90 インターフェース 文字列と数値の変換など 内部用汎用ライブラリ dc_string gtdata_generic 各種のデータ形式を抽象化した多次元数値データ アクセスライブラリ (データ形式の違いは下層のライブラリによって吸収) dc_trace dc_error デバッグ用モジュール エラーの処理 ??_generic その他の形式の データアクセス用 下層ライブラリ （未定） an_generic 『このソフトウェアのユーザから見た特徴は次でしっかり話すとして、まず簡単にgt4f90io の内部構造を紹介します。』 『この点線で囲まれた部分が gt4f90io です。上のこれが数値モデルで、下のこれが netCDF ライブラリなどです。』 『先ほど、gtool4 プロジェクトの目的として、内部構造の階層化を上げました。実際に、内部はその役割に応じて3 つに階層化されています。まず一番下にあるのが netCDF データ用のライブラリ、真中のが数値データを取り扱う本体部分です。そして、上にあるのがユーザインターフェースです。実際には 100 を超える Fortran90 プログラムがありますが、Fortran90 のモジュール機能を用いて、明確な階層化を行っています。』 ・お話 『3 つに階層化されています。まず下にあるのが netCDF データ用のライブラリ、真中のが数値データを取り扱う本体部分です。そして、上にあるのがユーザインターフェースです。実際には 100 を超える Fortran90 プログラムがあるが、Fortran90 のモジュール機能を用いて、階層化をうまく行っていることです。 』 『3 つに階層化されています。まず netCDF データアクセス用の下層ライブラリ、netCDF のデータ形式を扱う、ということに関してはこのライブラリで閉じています。そして抽象化された多次元数値データを扱う中層のライブラリです。そして、これはユーザインターフェースとなる上層ライブラリです。後は内部の様々なところで使うような汎用のライブラリがまとめられたライブラリがあります。あと、sysdep…。で、例えば他の形式のデータアクセスを…実際には 100 を超える Fortran90 プログラムがあるが、Fortran90 のモジュール機能を用いて、階層化をうまく行っていることです。 』 ・ 、役割としては上記のように統一されている。 ・ 全部で 15000 行、500000 バイト ・『API』 = 『Application Program Interface』 ・『Specialized』＝「限定される」 ・『Subarray』＝『』 sysdep netCDF データアクセス用下層ライブラリ。 netCDF 変数の入出力ファイルのオープン、 入出力範囲の保持、属性の文字列変換など Fortran コンパイラに 依存するコードの共通 インターフェイスを提供 その他のデータアクセス ライブラリ (未定) UNIDATA netCDF Library

特徴 簡単インターフェース 覚えるべきは… 多次元格子点データを簡単に出力 モジュール名 gt4_history 最低限たった 4 つのサブルーチン 多次元格子点データを簡単に出力 正確には gtool4 netCDF 規約に基づくデータ 『では、利用者側から見た gt4f90io の特徴はなんであるかといいますと。簡単に利用できるユーザインターフェースを提供するということにつきます。』 『具体的には、gt4_history というモジュール名、そして最低限たった 4 つのサブルーチンだけで、gtool4 netCDF の規約に基づくデータ形式のデータを出力できる、という点にあります。』 『では、実際にどのようなサブルーチンを利用するのかといいますと、』 ※ 「次のスライドで」とか言うな!!! 『Fortran90 の netCDF インターフェースというものは存在し、手に入れる事は容易なのですが、 gt4f90io 無しで出力しようと思うと、 数多いインターフェース用のサブルーチンを利用しなければいけない上、規約を眺めながら、それに沿うような属性を一つ一つ設定しなければなりません。』

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

使用例 サンプル 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 を呼び出します。』

まとめ gt4f90io 御利益 http://www.gfd-dennou.org/arch/gtool4/ Fortran90 数値モデルから gtool4 netCDF データを出力 導入例 ：階層的地球流体力学スペクトルモデル集 SPMODEL http://www.gfd-dennou.org/arch/spmodel/ 覚えるモジュール 1 つ、サブルーチン 4 つ モジュール ： gt4_history サブルーチン HistoryCreate、HistoryAddVariable HistoryPut、HistoryClose 『…というわけで、』 『結局、ユーザのみなさんにどんな利益がもたらされるのかといいますと、まず、Fortran90 でかかれた数値モデルから、Gtool4 netCDF 形式に基づくデータを出力できることです。で、さらに、覚えるモジュールやサブルーチンの数が圧倒的に少なくて済みます。』 『なお、既にこれは、次に紹介されます、 SPMODEL で実際に使われてます。先ほどの例は非常に簡単な場合でしたが、こちらを見れば実際のモデルでどのように使われるかが良く分かると思います。』 『ちなみに、この gt4f90io ライブラリですが、このURL においてあります。使ってみたい、またはどんなものか見てみたい場合にはこちらを参照ください。』 ・お話 『 http://www.gfd-dennou.org/arch/gtool4/ には、その時々での最新版が置いてありますので、誰でも持っていく事が出来ます。』 『「階層的地球流体力学スペクトルモデル集 (SPMODEL)」で既に 「使われている」されていることを強調』 Fortran90 で書かれた数値モデルから、“gtool4 netCDF 規約” に基づく netCDF ファイルを出力 導入例として spmodel がある

課題 当面の課題 様々なプラットフォームでの動作テスト gtool4 netCDF 規約 への厳密な対応 動作確認 富士通 Linux 用 Fortran Compiler 3.0, 4.0 Intel Fortran Compiler 7.0, 8.0 (8.0.039以降) gtool4 netCDF 規約 への厳密な対応 推奨する他の属性も自動で netCDF ファイルに出力 データ入力時には、属性と規約との整合性をチェック ユーザフレンドリな「入力」用インターフェース開発 現在、データの入力には gt4f90io の下位のサブルーチンを自分で組み合わせることが必要 『ただし、またいくつかの課題も残っています。』 『まず、様々なプラットフォームでの動作テストです。まだ、恥ずかしながら、以下のものしか動作確認が終ってません。他のコンパイラに関しては、動作テストおよび移植中です。』 『それと gtool4 netCDF 規約へもっと厳密に対応することも課題です。既に、規約において必須と定められる属性に関してはちゃんと対応できるので、相互参照に支障はないのですが、推奨するほかの属性などに関してもファイルに出力するなどの機能を付加したいと思っています。』 『最後に、これは既に気になっている方もいらっしゃるかもしれませんが、先ほどの HistoryCreate などと並ぶ、ユーザフレンドリな入力インターフェースがまだありません。現在は、gt4f90io の下位のサブルーチンの組み合わせで、データを入力をできはするのですが、これに関してはちゃんと gt4_history モジュール内に HistoryGet という名前にするかは分かりませんが、そのような入力用インターフェースを用意するつもりです。』 『現在は、これらの開発を行っている最中です。』 『…というわけで、発表は以上です。なにか質問などありますでしょうか？』

メモ セミナー中のコメント (谷口) gt4f90io って普通の Fortran90 プログラムで動きます? (石渡) 綺麗に整列された格子点データを対象にしているなら問題ないよ (林) 格子点じゃなくても、非格子点⇔格子点データの手間を自分で負うならやれるけど? (堀之内) 出力ファイルをサイズやタイムステップに応じて分けれない? (森川) 現在は、原則1つの HistoryCreate で 1 つのファイルですね (堀之内) 今までの上にかぶせるように作ると良いね (林) 始めはサンプルモデルを作成してそれを公開するだね (堀之内) Gtool4 netCDF 規約との対応を書いてあると嬉しいね 例えば 「gt4f90io ver1.0 は gtool4 netCDF 規約 4.1 と対応 」とか

以降、付録(?)

参考資料 Toyoda, E., Ishiwatari, M., Takehiro, S., Hayashi, Y.-Y., gtool4 Devlopment Group, 2002: gtool4 Fortran90 Tools/Library, http://www.gfd-dennou.org/arch/gtool4/, GFD Dennou Club. Toyoda, E., Ishiwatari, M., Horinouchi, T., Akahori, K., Numaguti, A., Hayashi, Y.-Y., GFD Dennou Club Davis Project, 2000: gtool4 netCDF convention, http://www.gfd-dennou.org/arch/gtool4/, GFD Dennou Club. Toyoda, E., Takehiro, S., Ishiwatari, M., Hayashi, Y., 2003: GTOOL: I/O Library and Analysis Tool for Gridded Data, IUGG 2003 SW05 (Thu Jul 10 2003) , http://www.gfd-dennou.org/arch/prepri/2003/iugg/gtool/poster/note-iugg2003.html Takehiro, S., Ishioka, K., Toyoda, E., Ishiwatari, M., Hayashi, Y.-Y., SPMODEL Development Group, 2002: Hierarchical GFD Spectral Models (SPMODEL), http://www.gfd-dennou.org/arch/spmodel/, GFD Dennou Club. GFD Dennou Club, 2000-2003: Dennou Ruby Project . http://www.gfd-dennou.org/arch/ruby GFD Dennou Club, 1992-2002: DCL (GFD Dennou Club Library). http://www.gfd-dennou.org/arch/dcl University Corporation for Atmospheric Research/Unidata, 1993-1999: NetCDF. http://www.unidata.ucar.edu/packages/netcdf/index.html

総称手続き Fortran 90 コーディングスタイル 上位モジュール 下位モジュール オブジェクト指向“的”に… クラス → 構造型 メソッド → サブルーチン 多態性 (polymorphism) → 総称宣言されたサブルーチン 引数の型に合わせ、異なるサブルーチンが呼び出される (下図参照) 上位モジュール 《引数の型を気にせず、サブルーチンを呼び出せる》 総称名称 （例：HistoryAddAttr） ・『動的多相性：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 《引数の型に応じて実際に 呼び出されるサブルーチンが変化》 個別の サブルーチン 文字型用 論理型用 実数型用 例：HistoryAddAttrC 例：HistoryAddAttrL 例：HistoryAddAttrR 例：Histo.. 下位モジュール

gtool4 Tools/Library 詳細図

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

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, 0.03448276, 0.06896552, 0.1034483, 0.137931, 0.1724138, 0.2068965, : t = 0, 0.0005, 0.001, 0.0015, 0.002, 0.0025, 0.003, 0.0035, 0.004, 0.0045, temp = 1.38879542122922e-11, 3.87761921792298e-10, 8.53515772443671e-09, 解析 and 可視化 by RubyNetCDF + RubyDCL + Gphys + … topology = "circular" ;

gt4f90io – Fortran90 netCDF I/O Library 正式名称 [日] gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ [英] Fortran90 netCDF I/O library with gtool4 convention 目的 “Fortran90 netCDF I/O ライブラリ” への機能の特化 & 強化 開発 & メンテナンスのコスト削減のため 可視化 & 解析には、 Dennou Ruby Project のツール群を使用 結果として DCL から独立 構想 解析コマンド群 数値モデル 可視化コマンド群 非依存 gt4f90io – Fortran90 netCDF I/O Library RubyNetCDF + … NetCDF Library その他のデータアクセス ライブラリ (未定) DCL Library

目次・旧 1. これまでの取り組み 2. gt4f90io 3. 参考資料 1-1. GTOOL3 2-1. 概要 2-2. 構造 2-3. コーディング 2-4. 使用例 2-5. 使用結果 2-6. 課題 2-7. まとめ 2-8. URL 3. 参考資料

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

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

背景 【2】 (以前の発表資料の残骸) 共同研究でもデータの効率的な相互参照は必須 階層的モデル群による アプローチ 地球大気との比較 『このようなコストを気にするのは、我々の研究分野や研究スタイルに大きく関係しています。我々の研究グループでは、地球や火星の、現在そして過去の気候や気象に関して、いろいろなモデルで実験を行い、それぞれのデータの比較を行っています。』 『具体的には鉛直1次元の放射対流モデル (左上)や南北1次元のエネルギーバランスモデル (EBM)や、2-3次元の雲解像モデル(右上)、他にも3次元のGCM(左下)による数値実験を行っています。このような大規模なプロジェクトになりますと、数多くの研究者の間でデータの相互参照が頻繁に行われます。このような時、誰でも、「データがパッと見れ」たり、次元の異なるデータを「パッと比較できる」ことが必要とされています。』 【そしてそれぞれのモデルの結果を対応付けるなどして考察を行います。この際に、 】 【図の真中の、「地球大気と火星大気との比較」、「現在と過去の気候の比較」を「階層的モデル群でアプローチ」しています。各モデルの話はする。効率的に「データがパッと見れる」とありがたいということだけ言う。めんどい話はしない。】 『このようなコストを気にするのは、我々の研究分野や研究スタイルに大きく関係しています。我々の研究グループでは、地球や火星の、現在そして過去の気候や気象に関して、様々なモデルによる実験や考察を行っています。』 『具体的には鉛直1次元モデル (左上)や南北1次元モデル (EBM)、そして2-3次元の雲解像モデル(右上)や全球を覆うような3次元球面モデル(左下)による実験を行っています。そして例えばGCM で出て来た結果を鉛直1次元モデルや南北1次元モデルと対応付けるなどの考察を行います。この「考察」の場合に、異なる研究者、または研究グループ間でのデータの相互参照が行われます。このような時、効率的に「データがパッと見れる」とありがたいのですが、現状では、そのデータがなんであるか、またデータを扱うためにどんなツールが必要かなどを教えあわなければなりません。当然、データの相互参照は頻繁に行われるので、一つ一つのコストはたいした事が無くとも、塵も積もれば山になるで、非常に大きなコストとなってしまいます。こういったことから、データの効率的な相互参照が行えることが切に望まれています。』 ・おはなし 『我々はこんな事をやってます。気候、気象、地球、火星、現在だけでなく、過去の状況、様々なモデルによる実験と考察。モデルによる実験とは鉛直1次元モデル (左上)、南北1次元モデル (EBM)、2-3次元の雲解像モデル(右上)、全球を覆うような3次元球面モデル(左下)。考察とはGCM で出て来た結果を鉛直1次元モデルや南北1次元モデルと対応付ける事。この「考察」の場合などに、データの相互参照が行われる。(できるだけ具体的に) 具体的に、効率的なのは、「データがパッと見れる事」具体的に非効率なのは、付加情報が必要になる上、環境を構築しなければならない。※ 自己記述的とかのさらに細部の話はここでは要らない』 『それぞれ違うモデルを使用して研究をしている研究者同士が互いのデータを見たい、使いたいときもあります。そのような場合に、常にデータのみならず、その内容、使うための手段を教えなければならないのは非常に面倒です。また、あらゆるデータを見るためにいろいろな環境をインストールしなければならない。ちなみに、これは我々の研究グループが行っている共同研究の概略図になります。このように我々にとってこのデータの効率的相互参照は重要です』 GCM、EBM、CRM (対流解像モデル)、 1D-RCM (1次元放射対流モデル)、観測データのそれぞれの比較が必要となる。それらによって生成されるデータが異なる形式の場合には、それぞれを扱うためのツール (環境) が必要となり、面倒である。それらを簡単に比較できるためには同様の形式のデータに書き出すことにし、同じツールを共有するのが便利である。

背景 【3】 (以前の発表資料の残骸) 大学なので… 公共財として利用したい オープン／フリー 研究教育資源としてデータやツールを提供 誰でも自由に参照 オープン／フリー みんなで使える (データの共有) 改変が自由 再配布も可 『それに加えて、』 『主に大学での研究が中心となっていることもあり、教育目的で誰でもが自由に利用できる、オープンでフリーなデータ形式やツールセットが必要になります』 【僕が作ったデータは先生なり、他の共同研究グループの人なりが使えた方がありがたい。】 【大学なので、授業で配布できるようなデータ、ツールセットが良い】 『また、主に大学での研究が中心となっていることもあり、オープンでフリーなデータやツールがあると良いな、と考えています。現在、様々な、データの形式や解析・可視化などのツールセットが存在しています。そういった既存のものを利用するという手もあります。でも例えば、自分達が作ったデータを教育用として学部などの研究グループに属さないような学生に使ってもらおうと思っても、商用のものだと事実上無理なわけですね。そういったことを可能にできるようなものがあったらよいな、という考えがあります。また、例えば僕が就職した際にライセンスなどの問題で使えなくなってしまうものだと困るので、所属する組織に依らずに利用できるものであるといいなと考えます。』 ・お話し用ノート 『売っても良い』 『現在、様々な、解析や可視化などのツールセットが存在します。（grads とか）。そういった既存のものを利用するという手もありますが、出来得るならば、以下のような要件を満たしているツールセットがあったらいいな、と考えています。一つは公共財として利用できるようなものであったらいいな、ということです。例えば、自分達が作ったデータを教育用として学部なりなんなりの学生に使ってもらう際に、商用のものだと事実上無理なわけですね。そういった、だれにでも使えるようなものだといいな、というのが一つ目です。従ってオープン／フリーで、改変や再配布の自由なものであるといいな、と思います。これも例えば、誰かが既存のツールを手に入れて、ちょっと改良したいな、と思った時に、。また、僕が就職した際に使えなくなってしまうものだと困ります。』 GCM、EBM、CRM、IDEM、観測データのそれぞれの比較が必要となる。それらによって生成されるデータが異なる形式の場合には、それぞれを扱うためのツール (環境) が必要となり、面倒である。それらを簡単に比較できるためには同様の形式のデータに書き出すことにし、同じツールを共有するのが便利である。 背景 コンピュータの進歩とネットワークの成長により、科学者は巨大で多種多様な形式のデータをより効率的に扱う必要と直面している。 共通のデータ形式を作り、ソフトウェアを共有することで、それらの労力を軽減できる。 地球流体 (すなわち、大気、海洋、地球内部)を扱うデータのためのソフトウェア環境 “gtool” に関して報告する。 『これまでの取り組み』 = 『gt4f90io に先立つ取り組み』

目標 (以前の発表資料の残骸) データの氾濫を乗り切るために必要なもの 作りたいもの 効率的な相互参照が可能なもの オープン/フリーなもの 地球科学に適したもの 作りたいもの ネットワーク透過的なファイル形式 自己記述的なデータ形式 いろんなところで使えるデータ I/O ライブラリ いろんなところで使える解析・可視化コマンド群 『そういったわけで、効率的な相互参照が可能な、自己記述的、かつネットワーク透過的なデータ形式と、そのデータを使えるデータ I/O ライブラリ、解析・可視化ツール群を作ろうと考えています。』 『なお、これらは全て (さっきの話にあったとおり) オープン／フリーで地球科学に適したものにします』 『そういったわけで、これまでにお話しした要件を満たす、以下の4つのものを目標としています。』 『1つめ、2つめは特に効率的な相互参照と関わりますが、1つめはネットワーク上を透過的に持ち運べるようなファイル形式です。2つめはデータ自身の情報をデータ内に含むような自己記述的なデータ形式です。 3つめ、4つめは、そのデータを扱える、データI/Oライブラリと解析・可視化コマンド群で、様々なプラットフォームでの利用ができ、オープンでフリーなものであるようにと考えています。』 【上下のつながりをいくらかしゃべる】 『そういったわけで、このようなことを目標としています。』 『まず、データの氾濫を乗り切るために必要なものの要件として、効率的な相互参照が可能なもの。そして、オープン／フリーなもの、さらに地球科学に適したものの3つを考えています。』 『そして、具体的に、どういったものを作りたいかといいますと、1つは、機種などに依らず、どのようなプラットフォームでも利用できるような、透過的なファイル形式です。もう一つは、効率的な相互参照を可能にする、自己記述的なデータ形式です。そして、様々なプラットフォームで利用が可能なデータの入出力ライブラリと解析・可視化のツールセットです。』 ・お話 『いろんなところで使える』＝「様々なプラットフォームで利用できる」 背景 コンピュータの進歩とネットワークの成長により、科学者は巨大で多種多様な形式のデータをより効率的に扱う必要と直面している。 共通のデータ形式を作り、ソフトウェアを共有することで、それらの労力を軽減できる。 地球流体 (すなわち、大気、海洋、地球内部)を扱うデータのためのソフトウェア環境 “gtool” に関して報告する。 『これまでの取り組み』 = 『gt4f90io に先立つ取り組み』

gtool4 Fortran90 Tools/Library gt4f90io [Fortran90 netCDF I/O library] 現在の取り組み (非採用バージョン) 今までの取組み gt4f90io 数値モデルのデータ I/O ライブラリとして特化 単独のツールとして再パッケージング gtool4 Tools/Library I/O ライブラリ + 解析・可視化コマンド群 Fortran 90 で記述 ： モジュール、構造型、総称手続き を活用 ファイル形式は netCDF ： 高移植性、多次元データ、自己記述的 構成 [日] gtool4 規約に基づく Fortran90 netCDF I/O ライブラリ [英] Fortran90 netCDF I/O library with gtool4 convention gtool4 Fortran90 Tools/Library gt4f90io [Fortran90 netCDF I/O library] 数値モデル 解析コマンド群 可視化コマンド群 I/O ライブラリ NetCDF Library その他のデータアクセス ライブラリ (未定) DCL Library 『…とこのように考えていたのですが、最近の計算機環境の発達もあって、解析ツールや可視化のツールに関してはオブジェクト指向のスクリプト言語である Ruby で作った方が楽でいいものができるようだったので、gtool4 プロジェクト自身で、Fortran で書くのは止めようかということになりました。 現在、正にこのワークショップを主催してます、電脳rubyプロジェクト (2003) でそのためのツールがちゃくちゃくと作成されありますので、そちらに依存しようか、という方針になっています。』 『データ I/0 ライブラリは、Fortran90 での開発を続ける事としました。数値モデルが Fortran90 で書かれる事が大半なため、Fortran90 の I/O ライブラリの方が親和性に優れるというのがその理由です。ツールセットとしては、解析・可視化部分を取り外す事となったので、名前を 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」を参照のこと 解析、可視化コマンド群を分離 オブジェクト指向スクリプト言語 Ruby へ gtool4 netCDF 規約 引き続き策定継続

GTOOL3 (1989) [no animation] Fortran77 で記述 構成 GTOOL3 Library 数値モデル I/O ライブラリ 解析コマンド群 可視化コマンド群 DCL Library 文字処理、数値基礎処理、 可視化ライブラリ 『まずgt4f90ioより先に、そのルーツとなるソフトウェアを 2 つ紹介します』 『最初に取り組んだのがこの GTOOL3 です (1989～1990)。作者は当時東大理学部にいらした沼口さんです。AGCM5の一部でもあります。この GTOOL3 は、数値モデルのI/Oとして使えるライブラリと解析・可視化のコマンド群を含むツールセットでした。先ほどはI/Oライブラリの話をしましたが、GTOOL3では、それによって入出力されるデータを解析・可視化するツールも含んでいました。解析・可視化部分は、右下の DCL Libraryという、文字処理、数値基礎処理、可視化のライブラリを用いています。なお、言語はFortran77 を用いています。』 『データ形式としては Fortran sequential unformatted ファイルを採用しています。これはヘッダ部分にデータ名や次元サイズ、作成日などの情報を格納する事ができていまして、自己記述性をある程度実現できています。』 ・お話 『今までにも、要件を満たすような、いろいろなソフトウェアの開発を行ってきました。最初に取り組んだのがこの GTOOL3 です。この GTOOL3 とは…で、右下に DCL Library というのは我々の共同研究グループである地球流体電脳倶楽部の共同研究者が開発した文字処理、数値基礎処理、可視化のライブラリで、GTOOL3 はこの DCL Library の可視化機能をライブラリとして用いています。データ形式としては…。時間に関しては、sequential なので、一度に書き出す 1 レコード 1 レコードを時間の 1 ステップと扱うようにしています。』 ・GTOOL3 は 1995 年のもの ・『Fortran sequential unformatted ファイル』 - 磁気テープに保存する事を想定 - 1 レコードごとに「ヘッダ」部と「データ」部があり、ヘッダ部にデータの情報が格納されている。（実は、ある程度描画情報も含まれている。） ・ 時間に関しては、 1 レコード 1 レコードを1 時間ステップとして取扱っている. ※ 1 レコード -- Fortran では, 1 度で書き出したものを「レコード」と呼ぶ. つまり, あるプログラム等で3 回書き出しを行ったのならば, それには 3 レコード分あるということである. GTOOL3 データ構造 Fortran sequential unformatted ファイル 自己記述性を (ある程度) 実現 ヘッダ部分にデータ名や次元サイズや作成日などの情報を格納