Subject: meeting memo 8/3 revized From: HAYASHI Yoshi-Yuki To: dennou_davis@gfd-dennou.org Date: Wed, 04 Aug 1999 17:21:50 +0900 X-Mailer: Mew version 1.93 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Delivery-Date: Wed, 04 Aug 1999 17:22:10 +0900 Mailing-List: contact dennou_davis-help@gfd-dennou.org; run by ezmlm 石渡です. 8/3 のミーティングメモです. # 表題 データ構造 # # 1999/08/03 石渡正樹 # 1999/08/04 林祥介 # ========================================================================= 項目 ・事務連絡 ・dennou server 群の増強計画(先日のおさらい) ・dcl C 化問題 ・ライセンス問題 ・ドキュメント製品 ・データ構造 ========================================================================= ■事務連絡 ・JUS ミーティング/ Ruby workshop http://www.jus.or.jp/workshop/ruby.html 9 月 4 日 (土) 朝 9:00 〜 5:00 於 東京ニューオータニ 後藤さんがパネリスト講演します: Ruby による地球流体データの扱い 出席できる人は出席して下さい. 沼さん万障くりあわせてね. ・Ruby な情報源 http://www.netlab.co.jp/ruby/ http://ruby.freak.ne.jp/ 本は 9 月に出るらしい. ・業務処理 該当者は 6 月の東京の分と 7 月の京都の分の出張報告書にハ ンコをもらって(誰にもらうかは知らない. 常勤スタッフの場合 は事務方の誰かだろう) JST の佐藤さんに送るように. 詳細はメール参照. ■ 先日のおさらい: dennou server 群の増強計画 サーバの方は塩漬け(京都, 九州に送って使い倒す人が使い倒す) 現 dennou サーバにdisc を増設する ■ dcl C 化問題: 先日のおさらい + α (1) 大枠 DCL の皮を作る. 最終目標 立派な C の皮を作って F90 インターフェースは C の皮を呼ぶ. Ruby インターフェースも C の皮を呼ぶ. 当面の手順 F90 インターフェースの整備固定 下側は既存 F77 版. 同時に C インターフェースの整備固定 下側は既存 F77 版を f2c したもので 必要に応じて c で差し替えたものをいれ る. Ruby インターフェース 固定された C インターフェースを呼ぶ. C 化の手順捕捉 f2c による安直な C 化+インターフェース(いわゆる皮) でいく. FIPによる C 化したやつの解説はまた後程. libf2c 問題はまだ解決されていない. 新しい皮のインターフェースルーチンの名前は, 例えば, DclDrawLine(X,Y, INDEX=3, TYPE=3) てな感じ. それで INDEX=3, TYPE=3 は省略可にするとか (2) 新しい皮の呼び方に関する議論 こういう書き方って, 他の言語は大丈夫だっけ? C だったら汚い書き方をすれば大丈夫だけどお勧めできない(豊田) ruby だったら簡単にできる(ごとけん) この皮のレベルでは, fortran でも c でもほとんど 同じにしておきたい. 渡し方の省略の仕方などは問題 どういう風にするか詰めるのに結構時間かかるんじゃない(塩谷) 省略形で f90 と c で形があってなくても良いんじゃない(林) 全てを包括するようなかぶせ物を作ろうと思わなくて 良いんじゃない(塩谷) 日付ルーチンが問題かもしれない. システムの時計のいちいち呼びにいくのは面倒くさい. C 用の皮の責任者はとりあえず塩谷さん. かぶせ物の引数の渡し方の原則はどうするの?(沼口) 全部ポインタ渡しにするのか, そうでないのか? 中で使う変数は参照渡しにしたい. 値として返ってくる物は返り値として返すように するのが良いのでは? でもそれだと配列が返って くる場合が問題. 酒井さんは基本的にサブルーチンを想定している. ちなみに, NetCDF ver 3 では全て関数になっている. でも, 関数だと色つかないじゃん. (3) 仕事の分担 FIP さんには, F90 のインターフェース文の集まりを書いてもらう. その時に, できれば, input か output の区別も つけてもらえると良い. libf2c 相当品の作成 文字処理が問題では? hop をやってもらったら, 足りないのは 20〜30. ファイル入出力, コンソール入力, 文字列比較, 内部変数のread/write, 数学関数などなど もうちょっと上のレベルでがさっと入れ換えても良いかも しれない(沼口). f90 用かぶせ物の担当は引続き酒井さんにお願い. C 用かぶせ物の担当は 塩谷さんにお願い. (4) 酒井さんの新しい皮のデモ とりあえず USPACK, GSPACK こんなネーミングで良いでしょうか? 作業領域に張り付けてください. 基本的に Dcl + 動詞 + 対象 という形. 例えば, DclDrawAxis (5) その他 : dcl に対する要求他 下の部分でも, 見通しが良い所は C にしよう. 機種依存ルーチン扱いにしておけば, 管理もそれほど 大変にならんだろう. トレースバック機能をつけたい. 例えば, UDCNTR が何を呼んだかくらいどこかに記憶して おきたい. なので, 上部ルーチンが誰を呼ぶかのリストがあると 良いんだけど.... 変数の指定の仕方は, DclParmSet(ud:miss) ではなく DclParmSet(graph:miss) とか, もっと分かりやすいように書きたい. ただし, 旧パッケージ名と 1 対 1 対応する (ネーミングとして uspack と udpack は統合しない). プログラム中だけでなく, 環境変数・コマンドラインにおける指定も ud:miss ではなく, graph:miss という形で指定したいよね. 変数の指定の仕方で, 変更をずっと有効にする 一時的だけ変える の両方を許すようにしてくれると非常に便利(堀之内). 例えば, 環境変数で指定するとプログラムの実行中ずっと有効, プログラムの引数だけ変えるとその場だけ変える, などとするのも 良いかもしれない. (6) DCL 描画系 GUI インターフェースを改良したほうがええんとちゃうか?(by 後藤) TclTk を介して画像を張り付ける. 日本語張り付ける. bitmap. これらファンシーな機能は後年度送り. ■ライセンス問題 対外的: JST はプロジェクトに応じて公開するソフトウエアライブラリ というのを作りたい. 対内的: 谷口さんの部署 : 環境事業推進部 みどりの IRAS センサー の地上局のソフトウエアシステムを作る(システム全体 のデザイン等), というのがお仕事. 解析をする上で gtool を使いたい(IDL PV-Wave は高い!) ■ドキュメント製品 もとは何で書くの? 一番のおおもとは Frame Maker (Adobe 社)を使うのが 良さそうだ. html への変換もしてくれる. 売り物だよん. どこまで行けるのかは現在調査中(酒井). windows で作業を行い, 誰かが管理するという形にする. そういうのって, ネットでバーチャル共同作業をする時に困らない? (林) ソースコード自体のドキュメンテーションはどうするの?(沼口) 入出力パラメータくらいでもドキュメンテーションがあると非常に良い. モジュール宣言の所(変数宣言の所)で変数のコメントを是非付けて欲しい. それは, FIP プロジェクトで自動的にできるはず. ■データ構造 球面 4 次元データの場合を例として考えよう. 問題は, longitude が londitude であることが分かるためには, 何を知っていれば良いのか? どこのレベルで知っていれば良いのか? 以下その考察 沼口サンプルの EdgeData のようなきれいなデータの場合を考えちゃうと 単純に平均をとる-> 重み(dx)だけでいい. ラプラシアン, div, rot を取る時 : ベクトル解析公式における 各係数 座標変換公式を持っていればいい. 式で持っていると毎回計算しなきゃいけないから 効率が悪くなるかも? サイクリック属性は「物理量」の属性のところで, 指定するように するのがよかろう. 点か面か : 本当の point value か, point value であってもその回りの領域の 代表値であるのかetc の情報も必要. 点とその点が代表する領域の情報がいる. 箱の形をどう指定するか? 関数で指定しても良いけれど, それだと fortran ではつらいかな? 少なくとも複数の折れ線という情報を持つことを許す必要がある. 境界情報 : 例えば, 境界が大円であるか小円であるかの情報. 全部覆われていない場合はその情報を知っている必要が ある(積分する時アルゴリズムを変えないといけないかも しれないから). staggered の場合は, grid1 と grid2 の関係も必要. grid1 と grid2 の関係はデータは知らなくてもよろしい(堀之内) grid1 と grid2 の関係はデータは知っていた方が良い(沼口) あらかじめ, 「grid1 の間に grid2 が入ってます」という 情報だけでも与えておくと, いちいちサーチしなくてすむ ので嬉しかろう. フラグ立てたきゃ立てとけば良いのだ(芦野) どうせフラグ立てるんだったら, デフォルトの写像まで書いちゃえば いいんじゃない. 結局, 必要なのは, 座標変換公式 その点の代表性 : point, 領域 こういうキーワードと領域情報・境界情報 他の座標系への写像(特に, staggered grid の場合) 後は, 例題による試行錯誤かな? かなりの経験を積まんとしょうがないだろう. ■沼口 ruby 実装例の詳細解説/検討 ■今後の目標 ・ベースファイルは netCDF ・GTOOL な道具群は ruby ・とりあえずの描画エンジンは DCL ・GCM 等の I/O は netCDF インターフェース ■仕事の切り分け 1. DCL F90/C インターフェース 2. DCL ruby インターフェース 例題 dcl.c by 沼口 gtrb 参照 3. netCDF I/O な研究 Fortran / C からの読み書き netCDF でのタグのつけかた(ヘッダーファイルの書き方) 数値モデル I/O への実装 4. 抽象データ構造 データは何を知っているべきか. 5. Ruby による構造実験 例: 球面データ (GTOOL が想定していようなよくある GCM アウトプット) 例: スタッガードグリッドなデータ 6. Ruby な「データ」と netCDF なデータ間の I/O な研究 netCDF ファイルをデータのバケツとして用いる. ■宿題 1. DCL F90/C インターフェース > 酒井, 塩谷, 高橋, FIP 谷口, 高橋 夏休み中に目鼻をつける F90 インターフェース名前のとりあえず版は http://www.gfd-dennou.org/arch/davis/ex/1999-08-04-sakai/F90InterfaceList.0.1 各自検討して意見をメールリスト上で交換. 2. DCL ruby インターフェース > 沼口 (上記プロジェクトとすりあわせつ つ, 最終的には DCL C インター フェースの部分のみ呼ぶ. ruby に必要となる DCL C インタ ーフェースは沼さんから 酒井/塩 谷組に発注) 夏休み中に目鼻をつける 3. netCDF I/O な研究 > 豊田 顧問: 沼口, 堀之内, 赤堀 AGCM5, GTOOL での現状掌握 堀之内資源の掌握 4. 抽象データ構造 > 石渡, 豊田 特に名前問題 (ものを考えなくて良くする) 5. Ruby な構造実験 A. 規則的な格子点系で考える筋で一通り考える. 例題 1 : 球面 3 次元座標(いつもやってる GCM オウトプット) なデータの格納と表示をやってみなさい. : potential vorticity を計算しなさい. > 堀之内 (いずれ高橋) 例題 2 : B grid 上の南北風速と温度を別のファイルに持っている. ただ, それぞれのファイルは格子の位置は 持っている. それだけの情報から南北の温度フラックスを計算しなさい. それぞれのファイルが dx を持っていることにする場合はどうか? それぞれのファイルが dx を持っていないことにする場合はどうか? (その場合, Bgrid であること, 相方のデータが何であるかを 知っていることにする) : それぞれの格子点に補間してみなさい. : 東西フラックスと収束を計算しましょう. > 後藤, 沼口 B. 不規則なグリッドが並んでいる場合を考える人がいると良いだろう. > 沼口 6. Ruby な「データ」と netCDF なデータ間の I/O な研究 > 後藤 (もうある)