Subject: meeting memo 01/31 From: momoko@ees.hokudai.ac.jp Date: Mon, 31 Jan 2000 18:43:08 +0900 石渡です. 本日のミーティングメモです. ====================================================================== 2000/01/31 ミーティングメモ 参加者 : 豊田, 堀之内, 林, 中島, 赤堀, 石岡, 石渡, 塩谷 ● JST 発表予稿 〆切 : 2/10 分量 : A4 2 枚程度. タイトル : 地球流体解析のための数値データの構造化 林さんが下書きしました. 下書きと完成に至るまでの作戦は林さんのメールのとおりです. 合同大会発表の皆さん, 2/4 までに合同大会の予稿を作ってくださいね. でないと林さんが JST の予稿を完成できません. ● 合同大会発表 ruby 関係 : ごとけんさん. 旅費は...... まあ, なんとかなるでしょう. fortran 関係 : 豊田さん 都合が悪ければ誰かが代打. DCL 関係 : 酒井さん 予稿集登録はいろんなものが要ります. 予稿集原稿本文は全角 2000 文字です. 英文原稿もいります. 著者は ID 番号が必要です. 地球流体電脳倶楽部 Davis Project の ID は 003321 です. ● HDF (予稿のまとめで将来展望を語る際に HDF のことにも言及した方が 良いかしら? ということで HDF のこともちょっと調べてみました.) 将来的には, HDF と netCDF が統合されるらしいです. http://hdf.ncsa.uiuc.edu/ しかし, HDF format というのはよくわかりません. 画像に関するデータもしまってあるみたい. 第一印象は, 単に, 複数のfile をまとめただけなんじゃない? tar file とあんまり 変わらないんじゃない? ● あらま欲しき解析ツールの姿 将来構想で何を書くべきか, から話が派生して我々が欲しい解析・お絵書き ツールのイメージについて議論しました. COARDS Convention でも hdf でも GrADS でも世の中に存在する format にも対応したいよね. お作法がなってないファイルも読めるようにすると良いだろう. 例えば, long_name が定義されていないファイルを読んだ時でも 作業を止めてしまうのではなく, 適当に補って先に進んでくれる ようにしておいたりすると良いだろう. そういう複数の(あるいは他の) format に対する対応は, ツール(reader)のレベルで吸収するしかないですね. やり方(実装の仕方)はいろいろ考えられる. 例えば, コマンドラインオプションを指定するという やり方でも良かろう. また, 属性名の対応については, 変換テーブルみたいなものを 用意してやることになるかもしれん. 他 format に対する対応は, ruby を使ったツールであれば それほど難しくないだろうという印象を持ってます. 例えば, GrADS 形式をサポートするための作戦は, ctl ファイル を parse して, gtool4 規約に変換してやればいい. 将来的に ruby による解析 tool を作る際には, gtool4 規約で定められた属性リストを見て 必要なmethod は何か? を考えていく必要が あります. ● ruby 班の現状と課題 以上のような計画はいろいろあるんですが, 現状は多次元配列の扱いが 問題です, という状況です. 現在, 堀之内さんが作った class library がありますけど 非常に遅くて困ってます. ● 豊田さん作成の gtool4 規約の検討 皆さん, 読んでね. 質問・コメントはメールしてください. 当日, じかに豊田さんに質問・コメントをした人もその発言内容を 自分でメールしてください. ● 堀之内さんにお願い 文章書いてください. gtool をやめて IDL に走ったのはなぜなのか? IDL だと何が気持が悪いのか? ruby を使うとどういう風に気持良くなれるのか?