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

参加者

  • 石渡 正樹, 小高 正嗣, 高橋 芳幸, 杉山 耕一朗

 林 祥介, 佐々木 洋平,

森川 靖大, 土屋 貴志
山下 達也, 徳永 義哉

 (順不同, 敬称略)

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

  • dcmodel プロジェクトと gtool4 プロジェクトと同様に davis プロジェクトのプロジェクト名も変更する予定. davis プロジェクトの使用上の注意も作成する予定 (石渡)
  • dcmodel プロジェクトと gtool4 プロジェクトの中身の整理 (石渡) 「gtool4 とは」はあるけど, 「dcmodel とは」がないなどの 不整合を整理する.

dcpam4 の開発状況 (森川)

  • 一応リリースした.
  • DCPAM プロジェクトのトップページを書き換える.
    • spmodel のように, モデルの詳細情報などは一段下に さげ, 「dcpam によっておこなった計算いろいろ」を もうすこしトップページの上部に入れる. (現在, 「計算例」はページのかなり下のほうにある).
  • モデル本体の改良
    • dcpam3 に導入されていた ape 実験用物理過程をどんどん取り込む.
    • 初期値生成に関しての構造を 初期値の生成に関して のようにする.
    • 現在セミインプリシットになっているが, エクスプリシットスキーム にも変更できるよう改造 (8 月末あたりに).
  • ドキュメントの移行もこれから
    • ソースコードを直接いじらないレベルのユーザ用ドキュメント 『ごくらく 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 の代替になり得 るか? など)

gtool4 netCDF 規約の「引用文献」の CF 規約へのリンクの修正 (石渡)

現状の CF 規約のリンクは

standard name テーブルのリンクは

となっている. CF 規約自体のリンクは, http://www.cfconventions.org/ へ と転送されるが, standard name テーブルのページは転送されない. (つまりはリンク切れ)

それぞれ,

に変更する. (石渡)

ちなみにこの <URL:www.cfconventions.org> の 実体は <URL:cf-pcmdi.llnl.gov>

dcrtm

報告事項

Todo:

  • dcmodel の英語版ページからのリンクを作成 (日本語版は既にある)
  • 大気放射関連の理論マニュアルがあるかどうか確認

覚書

  • データが集まった時点で, 何種類の吸収成分気体(バンド) を考慮すべきか, 検討する
    • まずは可能な限り考慮する, でよいが, とある時点でバンドの 取捨選択をしないとたぶん計算できないモデルになってしまうだろう.
  • Appleby and Hogan (1984) の再計算は年度内にできてないと後々困る. (しかし, 放射のインターフェース (deepconv や dcpam などの メインプログラムとのデータのやり取りの仕方) の検討も必要なので, 大変)

deepconv

  • 並列化はじめました
  • 3 次元化はじめました (小高)
    • 乾燥対流を計算するコードを CVS root にコミットした.
      • 現在コードのチェック中.
        • 浮力流, 乱流パラメタリゼーション
  • 凝結成分の種類をもう少し簡単に変更できるように改良を始めた.
    • 目標は地球版よ木星版の実行プログラムをプリプロセッサを使って 単一のメインプログラムから作成すること
    • NH4SH の反応に関係するサブルーチンの整理を始めた

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 ファイルの書式について

これまで 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              ! 鉛直格子点数
/

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

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

  • 作業担当者: 佐々木

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

public :: rn, irm

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

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

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

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

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

gt4f90io の HistoryGet の仕様変更に関して

  • 数値型の time 引数をあたえることが可能な HistoryGet を復帰する.
  • 文字型の range 引数には, 必ず gtool4 変数のコンマ記法を与えるようにし, "10.0" のように数値だけ与えた場合にはエラーを返すようにする.
  • ユーザーには時刻で切り出したい場合には time 引数を使用することを推奨する. 時刻以外の次元で切り出したい場合には range 引数を使用することを推奨する.
  • したがって, spmodel のサンプルプログラムの修正は行わない.