# 表題 JST プロジェクト 1999-04-16 ミーティングメモ # # 科学技術振興事業団(JST) # 計算科学技術活用型特定研究開発推進事業(短期集中型) # 地球惑星流体現象を念頭においた多次元数値データの構造化 # # 履歴 1999/04/16 石渡正樹 # 1999/07/02 林祥介 (公開) # (1) お題目, 目標 「名目」 元もと我々が持っていたのは DCL, GTOOL, AGCM, 回転球殻モデル.... : FORTRAN77 可視化 データ形式, 処理 数値モデル | | GTOOL をオブジェクト指向パラダイムで書きかえる. 対流問題をほいほい解析したいetc 「仕事の中身」 ・既存資源の整理 : できることをきちんとやろう ドキュメンテーション(html 化, 英語化, man ページ) SGML を使うのはどうだろう? クロスリファレンスとかはできるんか? 式などはどうしたらいいんやろう? ソースコードのチェック 「FORTRAN 77 + C ちょっと」のソース達が 今様の環境でちゃんと動くか? debian 化する? FORTRAN90 用インターフェース(皮をかぶせる) ほんまは, 全部 C で書いて f77 用の皮と f90 用の皮を用意するのが いいんちゃうか ・新しい試み : でけへんかもしれんけどきちんと投資しよう GTOOL = 抽象データ形式 <= GCM, 数値モデル I/O 観測データのoutput interface | | プログラム言語 実装 => DCL かそれに変わるもの IDL (2) 当面の作戦 1. 大枠 そもそも「ジーツール」ってややこしい言葉や. GTOOL 沼口バージョン Gtool 新版 gtool=DCL + Gtool + AGCM というふうに読みかえてやればいいんや. この作戦でいけば DCL を整備するのは本業になるで. gtool= DCL + 可視化アプリ(含むGtool)その他 + AGCM 等 : : C とか C++ に : F90 : まあ F90 やろう にする : C++ : : ruby : まあ classical : Python : なC 化やろう : その他もろもろ : 最初は f2c でも: : いいだろう : : : ここで F77, F90 用, C 用 のinterface があればいい とにかくこのinterface を固定せな. ここはどんどん太っていくやろう ちょっと整理するのは無理かもしれん. ということで, interface の仕様の決定 DCL の核となる部分を C 化 「Gtool = 抽象データ形式」の試作 が主要なお仕事. 2. 現状の GTOOL の現状固定作戦. GTOOL はどうせ捨てるんやろう? そんな一生懸命やらなあかんか? 現在のデータ形式の仕様の分のドキュメントなんてしたくないわい. 今の資源で頑張りたいなら, 案1 : 沼口さんに頼んで, 彼が書いてくれたものをもって 完成品とする. という案もあるが.... そういうのよりは, NetCDF 日本語マニュアルをちゃんと作る, というほうが 金の使い方としては真っ当なのでは? だから, 現状固定は, ごくらく GTOOL かなんか+豊田コメント でもって終りにする. せいぜい 1 週間仕事. 3. ドキュメント整備 DCL の英訳のMMJ の発注はすぐにはできない(HTML 化しないといけないから). したがって英語回りの仕事はしばらくないので, NetCDF マニュアル の和訳は good である. NetCDF マニュアル. ただ, 実際に使う使う人はごく小数 FORTRAN 版 は 100 ページくらい. 100 ページ(どれくらいつまってるかにもよるけど) 単価は ページ 3000 円〜5000 円 --> 30 万 〜 50 万 和訳のプロジェクトを正式に認知してもらう 塩谷さんが聞いてみる. 翻訳権, 著作権問題が発生する? free で出すことにすればいいのでは? 4. DCL の改定 この 1 年間では… DCL の C 化, マニュアルをちゃんと作る あとは力の限り, 下のレベルのinterface(C-> f77, f90)をやる? それとも, 上のレベルに少しシフトした方がいい? コメント・意見 ・interface の仕様について 一番下のinterface (C -> f77) の仕様を決めるのは大変なのでは? クラスライブラリ化しないといけないのでは(酒井) math1, math2 に入っている機能の中には F90 にはいらないものが結構ある(max, min を求めるとか) それらは, F90 用interface には用意しない, C 用interface には 用意する, とかしないといけない. これらは, interface の中に入れてもいいか知れんけど (例えば, エラーメッセージを出すようにするとか) FAQ に書いとくだけでええやんか. NetCDF ではこういう wrapper が全部できてるので どういう仕組みでやってるのか調査したい. ・C++ だと難しい? C++ で作っちゃうと fortaran から呼ぶのが難しいかも知れないよ. だから他の言語から呼びたいのだったら, C で書くのが無難 一番下は C で書いて, C++ を使いたい人がいたら C++ のwrapper を 書けばいい. データベースの呼出ルーチンは普通 C で書く. 異なるデータベースでも同じ手続きで読むようにすること は比較的簡単に作れる(芦野). ・C だと遅くない? C でやると素直にdoble 化できるで. スピードも普通そんなにかわらんで(Intel はちょっと遅いかな). ・どこを C 化するか? (グラフィックス, I/O) math1, graph は C で書くのがいいだろう. math2 (FFT) などは fortran がいい人が多いだろうなあ. ・マニュアルについて C 用と fortaran 用で共通する部分の記述はどうしよう? 別途にするか? 5. practical な問題 どこまでを MMJ に頼めるか? DCL, GTOOL のドキュメンテーションの整備 まずは NetCDF マニュアルの和訳 どこまでを FIP に頼めるか? DCL の C 化 + f77, f90 用の皮を FIP さんに頼むのが best では? ●新しい Gtool へ向けての要望・その他 ・問題点は, データ構造の決定である: ヘッダに何を書くか? etc ・ユーザーの取り込みを考えたいなら.... GrADS からのコンバータを作るが良い. ・ヘッダの処理に関する要求 かけ算したら単位もちゃんとかけて欲しいわあ. 以上