dcmodel プロジェクト TODO リスト (2008-07-30 版)

モデルの支配方程式系およびその離散化に関する文書の整理

  • 方針
    • これまで「離散化マニュアル」と呼ばれていたもの位置づけを 変え, このマニュアルさえ見れば, モデルの支配方程式系, およびそれらを離散化した式, そして計算手順がわかるようにする.
      • これまでの「離散化マニュアル」という呼称を 「支配方程式系とその離散化」へ変更する.
      • 「支配方程式系とその離散化」マニュアルでは, 使用している方程式が与えられたものとして記述をはじめる. 式の導出などは, 別の文書としてまとめる.
      • 現在の定式化マニュアルに該当する部分は, 将来的には理論マニュアル のように複数のモデルから参照することが可能な文書として整理する.
  • ディレクトリ構造について

    dcpam, deepconv の doc ディレクトリは以下のようにする.

    doc/
    |
    |-- basic_equations   支配方程式系とその離散化
    |
    |-- derivation        導出に関する参考資料
    |                     (完成度が上がったら理論ノートに昇格.
    |                      モデルドキュメントからはその理論ノートに
    |                      リンクをはるなどして関連付ける)
    |
    |-- code_reference    コードリファレンス (RDoc により自動生成)
    |
    `-- tutorial          モデル付属チュートリアル
  • 今後の手順
    • dcpam のドキュメントは上記の構造で作り直しているので, その作業を 引続き行う.
    • deepconv は流れマルチメディアの完成後, 改訂を開始. 現在定式化マニュ アル本文に記載されている基礎方程式のリストを離散化マニュアルにカット & ペーストする.
      • ディレクトリ名も dai1bu, dai2bu などとなっている ものを上記のように変更する.

dcpam/dcpam5 と deepconv/arare4 のソースコード比較

dcpam/dcpam5 (草稿 2008-07-09版) および deepconv/arare4 (20080627版) のプログラム構造およびソースコードの見た目について 比較を行い, dcmodel プログラミングスタイルとしてどのような 書き方を採用するのか検討した. (まだ議論中のものもある).

  • 演算モジュールの初期化について
    • dcpam5
      • 演算モジュールで初期化手続き終了の有無をチェックし, 初期化がなされていない場合は初期化手続きを呼ぶ.
    • deepconv
      • main プログラムで初期化手続きを呼ぶ. 手続き終了の 有無のチェック機能はない.
    • 今後の方針
      • 当面 dcpam5 はそのままのスタイルで書く. 一通り 計算できるモデルができた段階で, もう一度検討する.
  • 変数宣言での sava, public 属性の与え方
    • dcpam5
      • 変数の型宣言を行う際に, save, public 属性も付加する
    • deepconv
      • sava, public 属性は, 型宣言とは別に記述している
        • 情報が分散してしまう
        • 変数を 2 度書かなくてはいけない
    • 今後の方針
      • dcpam5 スタイルにそろえる
  • I/O
    • dcpam5
      • 方針: 出力変数の追加と削除が簡単に行えるようになって ほしい. そこで, AGCM5 のスタイルを参考にする.
      • 以下の 2 つの gt4f90io のラッパー手続きを用意, 新たに出力変数を追加するには, この 2 つの手続きを 呼ぶだけで OK (とする)
        • 出力変数の登録: HistoryFileRegister (仮)
        • 変数の出力 : HistoryFileOutput (仮)
          • 積算値も出力できるようにしたい
      • 出力したい変数のリストは NAMELIST に書く
    • deepconv
      • I/O モジュールのサブルーチンで, 一括して出力変数の登録, 出力を行っている
      • 複雑で面倒なプログラムになっている, 出力変数の追加と 削除するのが面倒
    • 今後の方針
      • dcpam5 のスタイルにそろえる
        • 平均値/積算値も出せるようにする
        • NAMELIST を使わなくても使えるようなラッパーで あってほしい

プログラムのコメントの書き方について

  • モジュール内のサブルーチン/関数の区切りについて
    • 空行一行では区切りがわからない
    • 空行を複数行入れると, 無駄な空行が残っていると勘違いする
    • なんらかの区切りは必要
    • 改善案
      • サブルーチン/関数の区切には, ハイフン "-" をある程度 (パッと見た目で区切りと分かるぐらい) 並べる
        • ハイフンの個数を具体的に取り決めて守るのはコストの方が 高いと判断し, 特に個数ついては決めない.

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

  • TODO
    • dcmodel プロジェクトと gtool4 プロジェクトの中身の整理 (石渡) 各項目の不整合を整理する.
    • プロジェクト全体の引用の仕方の例は

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

      とする. この例にならっていない gtool4 規約, deepconv プロジェクトの引用例を 修正すること. (石渡)

    • 引用の仕方の例における year をどのように書くかちゃんと すり合わせしておいた方が良いかもしれない.

DCPAM プロジェクト活動報告

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

dcpam4 から dcpam5 へ

dcpam4 の構造を見直し, dcpam5 を作成する. dcpam4 に関するコメント, dcpam5 の開発方針については 6/26 の dcpam 開発コアミーティング を参照のこと.

dcpam5 開発スケジュール

  • 〜 07/09
    • プログラムの顔つきを見るべく, 以下のものに関して 「こんな顔つきになるはず」というプログラム (ハリボテ) を作る. (森川)
      • データ出力は実際にできていなくて良い.
      • コンパイルができない段階でも, 形ができたら報告する.
      • 作成するファイル
        • メインプログラム
        • 定数設定モジュール
        • いくつかの演算モジュール
          • 放射過程
          • 乱流拡散
          • 積雲パラメタリゼーション
    • 上記のプログラムに関して, コメントをいれる (石渡, 高橋, 小高, 杉山, 中島)
  • 〜 07/16
    • ヒストリデータ出力モジュールの作成 (森川)
    • ヒストリデータ出力モジュールの arare への移植
      • 移植作業 (森川)
      • 使い物になるかチェック (小高, 杉山)
  • 〜 07/23
    • 力学過程の作成 (森川)
  • 〜 08/17 (天文台ミーティングまで)
    • dcpam4 に実装されていた物理過程を一通り実装 (森川)
    • 実行速度のチェック (森川)
      • AGCM5 と比べてどこが遅いのか?? なぜ遅いのか??
        • 最低限の目標: AGCM5 に比べ, dcpam5 の速度がどの程度か.
        • その先の目標: 遅い場合, その原因の追究.
  • 〜 08/20 (天文台ミーティング)
    • dcpam5 と arare4 のコードを眺め, 擦り合わせる

dcpam 開発に関する覚書

  • ToDo
    • 降水量などの時間平均値を出力できるように修正を行う.
    • 乾燥大気の平均分子量をモデルに対し与えるようにし, 気体定数などはその値から自動に求まるようにする (水蒸気などに対しても同様).

dcpam のモデルドキュメント整理 (森川, 納多, 石渡)

  • 全体構成の変更については モデルの支配方程式系およびその離散化に関する文書の整理 を参照のこと.
  • 力学過程については, dcpam のプログラムに沿った内容に変更した.
  • 物理過程については要チェック
    • 不足部分については追記する必要がある.
  • コード解説
    • AGCM5 の『コード解説』を dcpam 用に書き換えて 移植する. ディレクトリ名は code_description (仮).
    • ただし, これは RDoc ドキュメントを見ることでうまく コード内の変数と数式内の項との対応をつけられればなんとかなるか?? (やっぱり無理かもしれない).

dcpam4 にて行った実験についての備忘録

水惑星実験で AGCM5 と比較

  • 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)
  • 計算結果
    • お絵かき
      • 全球平均の図はまとめて上部に
    • 計算速度のチェック中 (環境研 SX8 にて).
      • プロファイラによるチェック中.
        • 速度は AGCM5 の 1/4 ぐらいだった(原因調査中)

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

  • 下記の計算を試みたが, そもそも乾燥対流調節, 湿潤対流調節など, 地球大気を想定した方程式を計算しており, 木星大気への応用がそもそも 可能かが怪しい.
    • この機会に方程式系を一度全て見直すと共に, 欠けている ドキュメントも作成する
    • 具体的な作戦は, 見直しが終わった段階で再考する.
  • 計算設定の詳細
    • 設定に関しては Sugiyama et al. (2008) ながれマルチメディア (投稿予定) を参考にする.
    • 半径は地球と同じ
    • 自転角速度は地球と同じ
    • 重力は Sugiyama et al. (2008) と同じく 23.1 [m s-2]
    • 乾燥大気の組成は Sugiyama et al. (2008) と同じ
      • 乾燥大気の定圧比熱 : 11900.9264 [J kg-1 K-1]
      • 乾燥大気の気体定数 : 3611.44466 [J kg-1 K-1]
      • 乾燥大気の平均分子量 : 2.3053533e-3 [kg mol-1]
        • He の分子量と割合 : 4.002602e-3 [kg mol-1], 0.1455
        • H2 の分子量と割合 : 1.00794e-3 * 2 [kg mol-1], 0.8531
    • 凝結成分は水のみ
      • 水蒸気の乾燥大気に対する分子量比 : 7.8250532
    • 初期値
      • 風速: 0 [m s-1]
      • 地表面気圧: 3.0e+6 [Pa]
      • 温度: σ=1 で 490 [K] とし, 気圧 1.0e+4 [Pa] となる高度まで, 温位一定で (乾燥断熱線に沿って) 高度に伴い温度を減少させる. 気圧 1.0e+4 [Pa] 以下の高度では温度一定とする.
      • 比湿: σ=1 で 6.11641e-3 [kg kg-1] とし, 比湿が飽和比湿の 75 % となる高度までは一定とする. その高度以上では, 比湿を飽和比湿の 75 % とする.
    • Sugiyama et al. (2008)と同じく, 2.0e5 [Pa] 〜 1.0e-4 [Pa] まで, 放射を模した一様冷却を与える. 冷却率は - 1.0 / 86400 [K s-1] とする.
    • Sugiyama et al. (2008) を模して大気上部でスポンジ層を入れるべく. 1.0e-4 [Pa] よりも上層では, 東西平均値に近づけるレイリー摩擦 (時定数は 86400 [s]) を与える.
      • Sugiyama et al. (2008) では CReSS ユーザーガイド 第2版 (6.188) と同様に レイリー摩擦を与えている. 本来は dcpam も同様に滑らかな 強制を与えるべき (ただし, E-folding time はモデルのタイムステップ に合わせて大きくする必要がある).
    • 境界条件
      • 地表面運動量・熱・水蒸気フラックスはゼロ.
      • 最下層中間 (σ=0.8987071) の温度を 490.0 * 0.8987071 ** ( 乾燥大気の気体定数 / 乾燥大気の定圧比熱 ) ≒ 474.374 [K] に固定.
      • 最下層中間 (σ=0.8987071) の比湿を 6.11641e-3 に固定.
    • 水平拡散は, 最大波数の波に対して E-folding time 10800.0 [s]. 超粘性の次数は 8.
  • 降水の扱いに注意
    • Sugiyama et al. (2008) では雲の微物理過程も考慮されているが, AGCM5 や dcpam4 では雨になったものは即座に除去されるという違いがある.
    • 従って, 下層で雨が蒸発することをいずれは考える必要がある. 木星の場合, 下層における雨の蒸発が循環を駆動するということが 結構効いていそうだから.

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

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

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

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

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

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

gt4f90io 関連

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

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

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

dcrtm

  • 報告事項
    • Appleby and Hogan (1984) 読書ノート作成中(徳永)
  • Todo:
    • 大気放射関連の理論マニュアルがあるかどうか確認(徳永)
    • 読書ノートのチェックを定期的に行う.
  • 覚書
    • データが集まった時点で, 何種類の吸収成分気体(バンド) を考慮すべきか, 検討する
      • まずは可能な限り考慮する, でよいが, とある時点でバンドの 取捨選択をしないとたぶん計算できないモデルになってしまうだろう.
    • Appleby and Hogan (1984) を光田放射スキームで再計算する. その際, 放射のインターフェース (deepconv や dcpam などの メインプログラムとのデータのやり取りの仕方) の検討を行う.

deepconv

  • 今後の開発の方針
    • 並列化・3D 版コードの作成を優先して行う
      • 並列化は 2D 版コードで開始, 天文台の計算機を積極的に利用(杉山)
      • 3D 版コードの作成(小高)
      • 主成分凝結過程モジュールの 2D 版コードへの移植(山下)
    • プログラムの構造・変数名・モジュール名に関する問題は後回し
      • 2D 版, 3D 版のソースコードの整理・統合は当面行わない
      • 現在の arare4 におけるプログラム構造・変数名・モジュール名を (可能な限り) 保持したまま, 地球, 火星, 木星等の大気の計算を行えるところまでコードを作成する. その過程で, 現状でのプログラム構造等の問題点も探る.
  • arare4 への主成分凝結モジュールの実装(山下)
    • 今後の予定・課題
      • 意味のある計算ができるようにプログラムを書き換える.
        • 時間発展方程式を主成分凝結系用に書き換える
        • main プログラム別個に用意する
        • 書き換え箇所を小高さんと一緒確認
      • モジュール名(cloudset)は変更せず, /src/moist/ に置くことにする
        • /src/moist/ 以下のモジュールを整理するときにモジュール名と置き 場所を再検討する.
  • arare3 を用いた北守修論の再計算(山下)
    • 北守さんの結果と比較できるように, 鉛直分布の図を追加
  • 3 次元化 (小高)
    • Odaka et al. (1998) の設定を与えた火星乾燥対流の計算を継続中
      • 1.5 次クロージャの乱流モデルを 3D 版コードに導入中
        • バグのチェック作業中
  • インストール手引きの改訂 (小高)
    • 山下が arare4 を動かし始めたら行う
    • ifc9.0 で動作させるために必要なソースコードの改変箇所を記述した

      手引の作成
  • 地形に沿った座標系の定式化ノートの作成 (山下, 石渡)
    • 時間を見つけて修正する
  • 関数名の変更についての覚書
    • 半格子<->格子の変換を行う関数に含まれる文字列 avr はとる.
    • Average モジュールは破棄. 3D 版と書法をそろえた xz_base_module を 2D 版で 使うようにする.
      • 理由は, 半格子<->格子の変換を行う関数(例 : xz_avr_pz) および, そのモジュ ールの名前 (Average) が良くないため. avr だと領域全体の平均操作を行う関数のように見えてしまう.
  • ifc9.0 でコンパイル時に生じたエラーへの対処の覚書
    • エラーを起こしたプログラム/モジュール
      • xyz_bc_module
      • xyz_module
      • xyz_deriv_module
      • xyz_deriv_c4_module
      • gridset_3d
      • chemdata
    • エラーは, use 文内で rename を用いている場所と, 引用した module の公開要素をカスケード公開している場所 で生じている
    • とりあえず, カスケード公開している公開要素は, 最初にその要素 が定義されているモジュールから直接引用するようにして, エラーを回避した.
    • 対策:
      • ソースコードレベルでは対応しない
      • ifc9.0 で動作させるために必要なソースコードの改変箇所を記述した 手引を別途用意しておく
  • 凝結成分の種類をもう少し簡単に変更できるように改良を始めた. (小高)
    • 現在中断中
    • 目標は地球版よ木星版の実行プログラムをプリプロセッサを使って単一のメイン プログラムから作成すること
    • NH4SH の反応に関係するサブルーチンの整理を始めた
  • 並列化 (小高)
  • TODO
    • 小高さんが復帰してから確認すべきこと
      • arare4 の 3 次元版で並列化の計算を行うための算段はどうなっていたか?
      • arare4 の 2 次元版と 3 次元版の管理はどのように行うことにしていたか? 2 次元版と 3 次元版でソースコードの共通化を行うことにしていたっけ?

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

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

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

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

  • 格子点配列の宣言について追記(佐々木)

各モデルの「チュートリアル」について

  • モデル本体に付属する, インストールから実行 (および簡単な実験) までの流れを記したチュートリアルは, 今のところモデルごとに 見た目 (名称や対象とするユーザ) が異なるため, 今後どのように 揃えるべきか要検討.

spml(佐々木)

  • spml における配列添字を 1 からではなく 0 から始めることへの修正
    • 佐々木変更分の trank へマージは終了
      • ドキュメントの rdoc 化は途中.
        • MathML を使用するかについて, 竹広さんと相談
      • インストールドキュメントを整備
    • sample プログラムの修正については今後行う
    • 参考: 天文台モデルミーティングログ 2006/12/25-27

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

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

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

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

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

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

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

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

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

AGCM5

  • ISPACK の SMPACK 対応版のコードに対する修正パッチを AGCM5 領域の agcm5-dvlop ディレクトリに格納(石渡)
  • TODO
    • AGCM5 のページに修正パッチへのリンクを作成する.(石渡)