2008/01/23 の dcmodel ネットミーティングのメモ書き

参加者

• 森川 靖大, 高橋 芳幸, 佐々木 洋平, 納多 哲史, 山下 達也, 徳永 義哉, 石渡 正樹, 小高 正嗣, 土屋 貴志

  (順不同, 敬称略)

次回日程

• 日時
  • 01 月 30 日(水) 13:30 - 18:00
• 場所
  • 神戸: 自然科学 3 号館 508
  • 北大: 理学部 8 号館 8-2-01 (コスモスタジオ)
  • 九大: 理学部 2 号館 中島部屋

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

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

• プロジェクト全体の引用の仕方の例は

  地球流体電脳倶楽部 hogehoge プロジェクト, year:URL, 地球流体電脳倶楽部

  とする. この例にならっていないものは gtool4 プロジェクト, gtool4 規約, deepconv プロジェクト. 修正する予定 (石渡,小高)

DCPAM プロジェクト活動報告

DCPAM プロジェクトの Web ページ整備 (森川)

dcpam4 モデル開発 (森川)

• 降水量などの時間平均値を出力できるように修正を行う.

dcpam4 のモデルドキュメント作成 (森川)

• ドキュメントの移行もこれから
  • ソースコードを直接いじらないレベルのユーザ用ドキュメント 『ごくらく DCPAM』の作成
  • ソースコードをいじるレベルのユーザ用ドキュメント 『らくらく DCPAM』の作成
  • 数理ドキュメント, 離散化ドキュメントは dcpam3 から単純移植予定.
    • 数理ドキュメントはコードに合わせた式にした方が良いか?? (DCPAM は U = u cos φ を使ってない, とか).
  • AGCM5 の『コード解説』に関してもコード内の変数を入れ替えて 移植する. ディレクトリ名は code_description (仮).
• これまでできたソースコード, プログラム構造, ドキュメントのチェック (石渡)

モデルの物理的保存性チェック

大気質量保存のチェック

大気の全質量の保存性をチェックする.

• Held and Suarez (1994) テスト
  • ページ末尾に, 以下の 3 通り計算の比較がある.
    • エクスプリシット法: Δt = 6 分
    • セミインプリシット法: Δt = 6 分
    • セミインプリシット法: Δt = 30 分
  • セミインプリシットに関するコードにバグがある模様. 要修正.

dcpam4 による実験 (森川)

水惑星実験で AGCM5 と比較

• 計算設定
  • SX を用いて, AGCM5 と dcpam4 とを同じ設定で動かし, 結果と実行速度を比較する.
    • まずは並列化でジタバタする前に, シングル CPU で動かす.
  • 積雲パラメタリゼーションとして 対流調節スキームを用いる. (AGCM5 では Mkinclude を編集して nonstd/p2cuma.F を用いるようにする).
  • 解像度は T21L16
  • 積分時間は 500 日
  • Δt は AGCM5 と dcpam4 とで同じにする
  • セミインプリシットスキームを使う
  • ヒストリデータの出力間隔は 0-100 日, 450-500 日に関しては 1 日おき, その他は 10 日おき. データは /GFD_Dennou_Work[3]/morikawa 以下に置く.
  • 出力変数は
    • 東西風, 南北風, 温度, 鉛直流(ソースコード要変更), 比湿, 加熱率分布 (DLscTempDt + DLscTempDt, DRadLTempDt, DRadSTempDt), 降水量 (Rain), 蒸発量 (DVerdiffQVapDt), 放射 (RadLFlux, RAdSFlux), 顕熱 (DVerdiffTempDt), 負の水蒸気除去量 (DNegQVapDt)
• 計算結果
  • そもそも大気の全質量 (Ps の全球平均) が減少しているのが変. Held and Suarez (1994) の結果をチェックしてみたところ, 質量が減少していることが分かった. まずは力学が 問題なので, そちらからフィックスする.
    • AGCM5 の計算結果 [Ps の全球平均の時間変化]
    • dcapm4 の計算結果 [Ps の全球平均の時間変化]
  • お絵かき
    • 全球平均の図はまとめて上部に
  • 計算速度のチェック中 (環境研 SX8 にて).
    • プロファイラによるチェック中.
      • 速度は AGCM5 の 1/4 ぐらいだった(原因調査中)

木星を念頭においた仮想惑星計算

• 計算設定は以下の通り
  • 半径は地球と同じ
  • 自転角速度は地球と同じ
  • 重力は木星 (Sugiyama et al. と同じ)
  • 大気主成分は水素 (Sugiyama et al. と同じ)
  • 水だけ (Nakajima et al. を参考に)
  • 地表面気圧の平均は 30 気圧 (Sugiyama et al. と同じ)
  • 地表面温度は全球一様で固定 (Sugiyama et al. と同じ)
  • 地表面水蒸気量も温度と同様 (Sugiyama et al. と同じ)
  • 2 から 0.1 気圧まで一様冷却 (Sugiyama et al. と同じ)
• 降水の扱いに注意
  • Sugiyama et al. では雨の落下も考慮されているが, AGCM5 では雨になったものは即座に除去されるという違いがある.

さらにその後の実験リスト (主に dcpam4 の動作試験としてのもの)

• 水惑星実験で AGCM5 と結果を比較する
  • 東西平均場の比較
    • 東西風, 南北風, 温度, 温位, 鉛直流, 比湿, 加熱率分布, 降水量, 蒸発量, 放射, 顕熱
  • 全球収支の比較
    • 質量 (地表面気圧), 水 (降水量, 蒸発量), エネルギー (放射, 凝結)
  • 波の活動度
    • Held and Suarez (1994) の Fig3, Fig4 を参照のこと.
    • 赤道の x-t ダイアグラム
• Held and Suarez (1994) の論文に載っている絵と同じもの を書いてみて波の活動度を調べるについて調べる.
• 地形を入れて計算してみる.
  • 余田グループの業績をチェックする.
  • Held and Suarez に地形を入れた計算を行った論文があるかも.
    • 高橋さんの調査では発見できなかった. 存在するかどうか もう少し調査が必要.
• それっぽい地球を動かす
  • 観測に基づく SST
  • 地形がある
  • 陸面過程がある
  • 水蒸気, オゾン, 二酸化炭素の吸収射出を考慮した簡単放射
    • 雲の放射も適当に考慮できるとよいだろう

dcpam3 での計算時のエラーに関して (石渡)

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

今後は, これまで dcpam3 に導入してきた物理過程を dcpam4 に導入して チェックする.

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

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

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

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

gt4f90io 関連

dc_date で 1 秒より小さい時間を取り扱えない問題

1 秒より小さい時間は, 足し合わせていくと丸め誤差が溜まって, どんどんずれていってしまう.

ちょっと試行錯誤して何とか取り扱えるよう試みてみる (森川)

dcrtm

報告事項

• 徳永さんの放射伝達の勉強を継続中.
  • Houghton の教科書第4章と第6章
  • 4 章は読破
  • Appleby and Hogan (1984) 読書中?

Todo:

• 大気放射関連の理論マニュアルがあるかどうか確認
• 卒論発表の内容をネットミーティングで話す(徳永)
  • 日時については後日相談(北大・神戸大・九大が参加できる日を探す)

覚書

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

deepconv

• 並列化 (小高)
  • 現在中断中
  • 詳細は 開発メモ参照
• 3 次元化 (小高)
  • Odaka et al. (1998) の設定を与えた火星乾燥対流の計算を継続中
    • dx=dy=200m, dz=100m とした計算 (気象学会で示した計算) を 平衡状態に達するまで継続
    • dx=dy=dz=100m に設定した計算を行う
    • 設定が間違っていたので、2 次元版から再計算を行う
    • 宇宙研の SX で 3 次元版を計算すると異常終了してしまう、原因調査中
• 凝結成分の種類をもう少し簡単に変更できるように改良を始めた. (小高)
  • 目標は地球版よ木星版の実行プログラムをプリプロセッサを使って 単一のメインプログラムから作成すること
  • NH4SH の反応に関係するサブルーチンの整理を始めた
• インストール手引きの改訂 (小高)
  • ifc9.0 で動作させるために必要なソースコードの改変箇所を記述した 手引の作成
• ifc9.0 でコンパイル時に生じたエラーへの対処 (小高)
  • エラーを起こしたプログラム/モジュール

　 * xyz_bc_module

• xyz_module
• xyz_deriv_module
• xyz_deriv_c4_module
• gridset_3d
• chemdata

• エラーは, use 文内で rename を用いている場所と, 引用した module の公開要素をカスケード公開している場所 で生じている
• とりあえず, カスケード公開している公開要素は, 最初にその要素 が定義されているモジュールから直接引用するようにして, エラーを回避した.
• 対策:
  • ソースコードレベルでは対応しない
  • ifc9.0 で動作させるために必要なソースコードの改変箇所を記述した 手引を別途用意しておく

• テスト計算を行っている最中 (山下)
  • 開発者 (杉山, 小高) 以外の人間がとりあえず動かせるかどうか, という意味合いがメインの「テスト」計算.
  • 他のテスト計算についても順次行う予定.

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

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

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

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

初期値生成コードの管理について

• 下記のような実装を dcpam4 において行った. これに関する解説文書をまずは dcpam4 の「らくらく dcpam4 」に まとめる予定である. (その後, dcmodel プログラミングガイドライン へと移動する予定.) とりあえずらくらく dcpam4 に文書をまとめるまで下記文書は ここに残しておく.
• 長期 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
    ｜
    └──────────────────

spml における配列添字を 1 からではなく 0 から始めることへの修正

• 佐々木が作業中
  • 作業用ブランチにおいてコードを修正中
• この修正に関する詳細については 天文台モデルミーティングログ 2006/12/25-27 を参照のこと.

spml のコード管理について

• ToDo (佐々木)
  • まっとうな spml のインストールドキュメントを作る

電脳 debian パッケージの公開方法について

stable, testing などではなく, sarge, etch などとする

• 現状
  • apt-line において stable と記述されている
    • 電脳サーバでは stable は sarge へのリンクのまま
• 以下の改正案を dcdvlop で諮った. 返事待ち
  • apt-line においてはコードネームを記述することにする
  • gtool4 などのインストール手引きにおいて stable と記述されているものを すべてコードネーム (現在は sarge) に変更する.

etch 版の Release.gpg に登録される鍵の共有化

• 現状
  • 佐々木個人の鍵が登録されている.
  • パッケージリストの更新は佐々木本人でなければできない (ただし現在は cron で 1 日 2 回更新している)
• 改正案
  • cc-env グループに入っているメンバーなら誰でもパッケージリストが更新で きるようにする
• 具体案を dcdvlop に提示する(佐々木)

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

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

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

実行時に演算プログラムを変更するための方法に関する議論

実行時に演算プログラムを変更できるようにすると, 実行速度 は低下することになるだろう. しかし実行時に演算プログラム を選択できる利点は大きいので, これまで考えてきた USE 文 を用いたプログラムの選択方法に抵触しない範囲でその方法を 検討してみる.

• ソースコードを変更することなく, 実行時に演算プログラムを変更するためには基本的に NAMELIST を使う
• 具体的な方法として, 以下の 2 つ案が挙がった.
  • 案 1
    • 切り替えを行う演算モジュールの1つ上位のモジュール で切り替えを行う.上位のモジュールの初期設定手続き において読み込まれる NAMELIST 変数群に演算プログ ラム切り替え用のフラグとなる文字型変数を含んでお き,その変数に与えられた文字列から, 演算するプログ ラムの切り替えを行う.実際には, そのモジュールの演 算プログラム内に, IF 文が出現することとなる.
  • 案 2
    • 切り替えられるそれぞれの演算モジュール自身で実際に 動作するかどうかのスイッチを持つ. 初期設定手続きに おいて読み込まれる NAMELIST 変数群にそのスイッチの 役割を果たす論理型変数を含んでおき, それが真の場合 のみ,演算プログラムの中身が有効となるようにする. つまり, 演算プログラムにおいて,このフラグが偽の際 には, 何もせずに返り値を返してプログラムを終了する.
• 案 1, 案 2 の場合ともにプログラムのどこかに IF 文を使 うことになる. したがってどちらにしろ計算速度が遅くなる ことは間違いない.
  • dcpam では時間積分法の選択を案 1 の方法で行っている. しかし計算速度の比較は行っていない.
• 案 2 はサブルーチンを呼び出すプログラム中に条件分岐が 陽に現れないため, 可読性が低下する恐れがある.
• 案 2 は NAMELIST 型で指定する論理型変数の値を間違える と, 同時に呼びたくないサブルーチンを呼んでしまうことが 起こってしまう.
• 結論
  • 案 1 の方法で演算プログラムの変更を行うようにする.
  • 案 1 の方法をどれだけ多用するのかはその都度考えて開 発を行うようにする.

AGCM5

• ISPACK の SMPACK 対応版のコードに対する修正パッチを作成した.
• ToDo
  • パッチファイルを AGCM5 領域の agcm5-dvlop ディレクトリに格納(石渡)