dcmodel プロジェクト TODO リスト (2009-03-19 版)

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

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

• ディレクトリ構造について

  dcpam, deepconv の doc ディレクトリは以下のようにする. (dcpam は変更済み)

  doc/
  |
  |-- basic_equations   支配方程式系とその離散化
  |
  |-- derivation        導出に関する参考資料
  |                     (完成度が上がったら理論ノートに昇格.
  |                      モデルドキュメントからはその理論ノートに
  |                      リンクをはるなどして関連付ける)
  |
  |-- code_reference    コードリファレンス (RDoc により自動生成)
  |
  `-- tutorial          モデル付属チュートリアル

• 今後の手順
  • deepconv は流れマルチメディアの完成後, 改訂を開始. 現在定式化マニュ アル本文に記載されている基礎方程式のリストを離散化マニュアルにカット & ペーストする.
    • ディレクトリ名も dai1bu, dai2bu などとなっている ものを上記のように変更する.
    • いくつか残っている和名なファイル (risan.tex, kyoukai.tex, kiso.tex 等) を一度に英名に変更する.

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 つの gtool5 のラッパー手続きを用意, 新たに出力変数を追加するには, この 2 つの手続きを 呼ぶだけで OK (とする)
      • 出力変数の登録: HistoryFileRegister (仮)
      • 変数の出力 : HistoryFileOutput (仮)
        • 積算値も出力できるようにしたい
    • 出力したい変数のリストは NAMELIST に書く
  • deepconv
    • I/O モジュールのサブルーチンで, 一括して出力変数の登録, 出力を行っている
    • 複雑で面倒なプログラムになっている, 出力変数の追加と 削除するのが面倒
  • 今後の方針
    • dcpam5 のスタイルにそろえる
      • 平均値/積算値も出せるようにする
      • NAMELIST を使わなくても使えるようなラッパーで あってほしい

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

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

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

• TODO
  • dcmodel プロジェクトと gtool4 プロジェクトの中身の整理 (石渡) 各項目の不整合を整理する.

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

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

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

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

dcpam5 開発

今後の開発計画

• 〜 2009/03 (森川)
  • ドキュメントの整備 (作業中)
  • 物理過程全体の構造の整理 (作業中)
  • ディレクトリ構造の整理
  • 速度と可読性 (書法のこだわり) が両立されているかどうかを評価
  • 軸対称モデルの作成
• 2009/04 〜 (高橋)
  • 物理過程間のインターフェースの設計と実装（？）

実験したいものリスト (主に dcpam の動作試験としてのもの)

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

覚書

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

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

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

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

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

gtool5 開発

• 〜 2009/03 (森川)
  • ソースの整理
    • モジュールごとにディレクトリを作成し, そこに当該モジュールに関連 するファイルを格納する. (現在は src 以下に150コのファイルがフラットに 配置)
  • ドキュメントの整理
    • 開発文書の整備
      • リファレンスマニュアルの作り方
      • Ruby による Fortran コード生成の方法
    • チュートリアルの整備
      • 並列化版 gtool5
  • 機能の追加
    • 並列化版では HistoryGet で統合入力を可能にする.
    • gtool_historyauto を用いた際に, 診断量出力に関する計算は, 出力時にのみ行えるような仕組みを考案する
• 2009/04 〜 (西澤)
  • オープン開発的な環境へ
    • 開発やソースの修正はみんなで行う.
    • 西澤さんはあくまで調整役.
    • 改変や改良が必要な場合, マンパワーは各人が調達 (?) してくる.
  • 懸案
    • 暦をどのように管理する枠組みを作るかを考える. (下記参照)

暦に関する ToDo

• 構造体 DC_DIFFTIME (dc_date_types モジュール提供) について
  • データとして dc_scaled_sec 型の秒だけ持つようにする
  • min, hour のみへの変換関数のみ残し, 他は削除する
    • うるう秒については保留
  • 機能により即した名前を考える
    • 候補
      • DC_ELAPSED_TIME
      • DC_ELPSTIME
• 構造体 DC_DATETIME (dc_date_types モジュール提供) について
  • 暦情報と基準日時と DC_DIFFTIME 型の秒を持つ
    • 暦情報そのものは DC_DATETIME とは別の構造体または モジュールで管理できるのが望ましい
  • 現在は day_seconds が暦と別に管理されているため, day_seconds も暦情報の一部として管理できるように 設計する
  • ユーザが 1 年が何日かを任意に設定できるようにする
    • 定数として渡せる
    • 関数として設定できる
  • 年や月という概念が不要な場合にも用いることができる ような暦も用意しておく
• Gtool_historyauto について
  • 現在は HistoryAutoPut の第一引数に DC_DIFFTIME 型の 変数を与えるようになっているが, これについても変更が 必要かもしれない. (現状のままでもよいかもしれず, 上記の実装が行われてから考える).

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 ??
• gtool5 の開発についていけない
  • (面倒) なんかいろいろ開発してるらしいが, ついていけん.
  • 時間が取れるときにフォローアップをする

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

実行時に演算プログラムを変更できるようにすると, 実行速度 は低下することになるだろう. しかし実行時に演算プログラム を選択できる利点は大きいので, これまで考えてきた 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 のページに修正パッチへのリンクを作成する.(石渡)

過去版 ToDo リスト

• 2008-07-30