2007/07/18 の dcmodel ネットミーティングのメモ書き

参加者

• 林 祥介, 石渡 正樹, 小高 正嗣, 高橋 芳幸, 森川 靖大, 土屋 貴志, 山下 達也, 徳永 義哉 (順不同, 敬称略)

引用例で挙げられるプロジェクト名がページによって異なっている問題

引用例で挙げられるプロジェクト名の呼び名がページによって 異なるものが出てきている. (RDoc の引用例と, dcmodel プログラミング ガイドラインでの引用例の dcmodel プロジェクトの正式名が異なっている). この件について, 他のプロジェクトの名称も考慮しつつ, どうすべきか 検討.

• プロジェクト名の変更に関して (森川)
  • 地球流体電脳倶楽部 数値モデリングプロジェクト dcmodel ⇒ 地球流体電脳倶楽部 dcmodel プロジェクト
  • gtool4 プロジェクト ⇒ 地球流体電脳倶楽部 gtool4 プロジェクト

cvs タグについて

現在いくつかのプロジェクトでは hogehoge-20070711 のようにタグをつけ ることにしているが, 同日中に複数回タグをつける際には, hogehoge-20070711-1 とすべきであったか, hogehoge-20070711+1 とすべき であったか, 石渡, 小高, 森川間でも既にポリシーがずれてしているので, 一度過去のログを参照しつつ確認する.

結論として hogehoge-20070711-1 のようにつける. 理由はあまり強い ものではないが以下の通り.

• debian 正規のパッケージには上記のように (日付)-(数字) のものが いくつかある.
• プラスよりもハイフンの方がファイル名, ディレクトリ名として一般的 (いまどきはプラスなどが入るファイル名も良く見るが).

これに関しては dcmodel ミーティング 2005-06-07 を参考に, dcmodel 開発者のための手引 に モデルプロジェクト CVS タグ付けの手引き を作成した (森川).

dcpam4 の開発状況 (森川)

• とりあえず, 初期値生成プログラムと主プログラムがビルドして 実行できるようになった. セミインプリシット時間積分も導入済み.
• まだ不備な点多々. 鋭意改善予定.
  • 現在 NAMELIST が使用できるよう改善中.
  • リスタートファイルの生成が不完全. (タイムステップが 1 つ分しか出力されていない)
  • そもそもまっとうに計算できているのか.
    • Held and Suarez 1994 やこれまで dcpam3 で行ってきた 計算をおこなってみる.
• ドキュメントの移行もこれから
  • ソースコードを直接いじらないレベルのユーザ用ドキュメント 『ごくらく DCPAM』の作成
  • ソースコードをいじるレベルのユーザ用ドキュメント 『らくらく DCPAM』の作成
  • 数理ドキュメント, 離散化ドキュメントは dcpam3 から単純移植予定.
    • 数理ドキュメントはコードに合わせた式にした方が良いか?? (DCPAM は U = u cos φ を使ってない, とか).
  • AGCM5 の『コード解説』に関してもコード内の変数を入れ替えて 移植する. ディレクトリ名は code_description (仮).

dcpam3 に関して (石渡)

計算していて地表面気圧がどんどん増えてしまう問題に関しては 調査を継続中. 目星はついてきた.

gtool4 netCDF 規約の CF 規約に対する位置づけに関して (石渡)

gtool4 netCDF 規約再検討北大メンバーミーティング ( 1, 2, 3 ) にて議論が中途半端になっている, gtool4 規約の今後について一応の方針を ちゃんと決める.

なお, 最近 (とはいえ既に昨年秋だが), CF 規約の White paper が公開されており, CF 規約のホームページ も新しくなっている. これらをチェックすべきかどうかも要検討.

現在, CF 規約の bounds について調査開始 (gt_calc_weight の代替になり得 るか? など)

dcrtm

活動開始.

• まずは木星大気の放射伝達を計算できるようになる, を目標に
• 詳細は dcrtm のページ
• 徳永君が放射伝達の勉強を始めた

Todo:

• 大気放射関連の理論マニュアルがあるかどうか確認
• 光田さんの放射計算コードを web に公開しておく

覚書

• モデルを作る, 読み解く上で必要な情報がどの論文に載っているかが だいぶ分かってきた. 詳細は杉山さんが調査中.
• データが集まった時点で, 何種類の吸収成分気体(バンド) を考慮すべきか, 検討する
  • まずは可能な限り考慮する, でよいが, とある時点でバンドの 取捨選択をしないとたぶん計算できないモデルになってしまうだろう

deepconv

• 並列化はじめました
  • 詳細は 開発メモ参照
• 3 次元化はじめました (小高)
  • 乾燥対流を計算するコードを作った.
    • 現在コードのチェック中.

dcmodel コーディングルールの修正

「リスタートファイルとヒストリーファイル」の 「ヒストリーファイル」に以下の記述を追記 (石渡)

平均値を計算する際に座標重みを必要とする数値データの場合には, 座標重
みのデータも各ヒストリーファイルに格納することを推奨する.

この際, 実際に netCDF ファイルにどのように座標重みを格納するかについても 記述する. これに伴い, これまでの gtool4 規約において gt_calc_weight として 使用されていた座標重み指定のための属性を CF 規約 bounds に置き換えることが 可能かどうかを調査する. (石渡)

初期値の生成に関して

• 長期 RUN 用実行プログラムは「お試し Run」できるように, 内部で 初期値を生成できるようにしておく.
• 本当に数値実験を行う際にわざわざ長期 RUN 用実行プログラムを改変 しなくて済むよう, 初期値生成用実行プログラムは別途用意しておく.
• ただし完全に別々に RUN 用ファイルと, 初期値生成用ファイルを メンテナンスする場合, 実際に初期値を生成するコードを「2 度書き」 せねばならず, 開発者のストレスが溜まる (deepconv 開発の経験)
• 現状の折衷案 (とりあえずこれで試行錯誤してみる)

  • 初期値生成「モジュール」を用意し, 実際に初期値を生成するコードは そのモジュールでくるんでおく. 別途, 初期値生成のみのための実行プログラム, 長期 RUN 用実行プログラムは用意する. それらの実行プログラムは初期値 生成モジュールを参照し, データを作成する.

    ┌─ initital_data.f90 ─────────────────
    ｜
    ｜  module initial_data
    ｜  
    ｜    subroutine InitialDataCreate( ....)
    ｜    
    ｜      初期値生成コード
    ｜      
    ｜    end subroutine InitialDataCreate
    ｜    
    ｜
    ｜  end module initial_data
    ｜
    └──────────────────
    
    ┌─ init_sample.f90 ─────────────────
    ｜
    ｜  program init
    ｜    use initial_data
    ｜    
    ｜    call InitialDataCreate(...)
    ｜    
    ｜  end program init
    ｜
    └──────────────────

  • RUN 用プログラムは「おためし RUN」可能なように, 初期値生成モジュールを use してサブルーチンを実行する.

    結果的に, 「おためし RUN」の際には, RUN 用ファイルは一度初期値ファ イルを書き出し, それを実行ファイルで読み込むことになる.

    ┌─ run.f90 ─────────────────
    ｜
    ｜  program run
    ｜    use initial_data
    ｜    
    ｜    call InitialDataCreate(...)
    ｜    
    ｜    
    ｜    do ....
    ｜    
    ｜      長期 RUN
    ｜    
    ｜    end do
    ｜    
    ｜  end program run
    ｜
    └──────────────────

NAMELIST に関して

• NAMELIST で, でかいデータは与えないようにする.
  • でかいデータは基本的にファイルで与える. 初期値ファイル, rst ファ イル以外のデータは 1 つにまとめるか, 複数かは適宜判断して使い分け る. また, 小さいデータは NAMELIST で与えることも許容する. ファイ ルを使うか NAMELIST でやるかも適宜判断して使い分ける.
• NAMELIST 変数の出力フォーマットについては全然話をしてない.

dcpam, deepconv の NAMELIST ファイルの書式について

これまで dcpam, deepconv の NAMELIST ファイルでは以下のように 変数グループを記述していた.

&grid_3d_nml
  im = 64             ! 東西格子点数
  jm = 32             ! 南北格子点数
  km = 16             ! 鉛直格子点数
/

これまで, frt, ifort, g95 で動作は確認されていたが, Fortran 95 規格 に正しく沿うと

&grid_3d_nml
  im = 64,             ! 東西格子点数
  jm = 32,             ! 南北格子点数
  km = 16              ! 鉛直格子点数
/

のように各変数はカンマで区切るのが正しいため, この書式に変更する.

なお, dcpam ではカンマが入っているものと入っていないものとがあったため, 一部の NAMELIST 変数グループが読み込まれないという事態が発生していた.

spml の wa_module から rn, irm を参照する問題

• 作業担当者: 佐々木

wa_module.f90 に以下の行を足してコミット.

public :: rn, irm

マイナーバージョンを上げて, リリースする.

その他 2006 年度末に話し合った内容に関しては, 天文台モデルミーティングログ 2006/12/25-27 を参照のこと.

gt4f90io の解説文書の英語化

そのうちやらないといけませんね...

最近作成された dc ユーティリティのチュートリアルに関しては 英語版を作る (小高)

モデル開発してて面倒と感じることいろいろ

以下の, 日頃作業する際に調べる面倒だなぁ, と思う事柄に関して, dcmodel のページから 1 ホップぐらいで手繰れるところに, 必要最低限の資料を作成 する. (杉山)

• cvs commit が面倒
  • (面倒) コマンドをすっかり忘れているので, わざわざいちいち調べなけ ればならない (コミットするのが億劫になる). 調べる情報も dcmodel プロジェクトの奥のほうにあったりして調べる作業も鬱陶しい.
    • 調べるものの例
      • cvs のタグの貼り方どうだっけ??
      • cvs のコミットどうするんだっけ?? なんかルールもあったような??
  • (対応策) 杉山氏が, 自分で cvs コミットの際に必要な情報を dcmodel ページの上の方 (検索しやすい位置) に作ってみる.
• ソースの公開版の更新が面倒
  • 作業そのものはだいぶ簡素化されている (タグが書き込まれているファイル を書き換え, あるディレクトリで make するだけ).
  • やり方が流布されれば OK ??
• gt4f90io の開発についていけない
  • (面倒) なんかいろいろ開発してるらしいが, ついてゆけん.
  • (解決策??) 基本的には History 系 (もうそんなに仕様変更されないことが 期待される) のみは追うけれども, 最近作っている目新しいツールは 無理して追いかけない. (面白そうならその時に聞く).