19-21 の dcmodel 開発合宿のメモ書き

参加者

参加者
- 林祥介, 堀之内武, 中島健介, 竹広真一, 石渡正樹, 高橋芳幸, 杉山耕一朗, 西澤誠也, 佐々木洋平, 森川靖大, 納多哲史, 山下達也

dcmodel プロジェクトのサマリー

モデルを構築する動機
- モデルを使って何をしたいか?
  - 主成分凝結大気の全球計算 etc.
- 短期目標と長期目標
- 研究計画から開発計画を立てる
目指していること
- 階層的なモデルの構築
  - 階層的モデル群: 単純から複雑まで複数のモデル?
    - 業界標準のモデルとそのバリエーション
- スタイルをそろえる
  - 計算を始めるまでの手順
    - 初期値の設定方法, 順序
  - メインプログラムの処理の順番
    - 例) 1. 格子点設定, 2. ...
  - 同じ形式の入出力データ
    - gtool によって実現
  - ドキュメントの形式
    - 数理ドキュメント, コード解説
条件
- 使い物になる程度には実行速度が速い
- 保守性が高い
出来ていないこと
- 複雑なモデルから strip down したモデル群
  - EBM, 1 次元放射対流平衡モデル
  - skelton な力学コア
    - GCM から物理過程を外したもの
- ドキュメントの作成
- 統一されたスタイルの実現に至っていない
- dcpam の並列化
問題点
- 実際に使うユーザが少ない
  - 我々があまり使っていない
  - 実際に使ってもらうためには?
  - 開発に加わらないと使えない雰囲気があった
  - 安心して使える部分がどこか分からない
    - 安定版が欲しい
  - ドキュメントが充実していない. サンプルが少ない.
開発のコスト
- スタイルを揃えるコスト
- gtool の複雑さ
優先順位を決める
費用対効果を考える

具体的な計算目標

ここでの「短期」は 1 年程度である.

dcpam
- 短期目標
  - 地球のような惑星 (高橋)
    - 海陸, 湿潤, 放射(CO2, H2O, O3, 雲のようなもの)
  - 金星のような惑星 (高橋)
    - ニュートン冷却, レイリー摩擦
  - 火星のような惑星 (高橋)
    - 放射(CO2, ダスト)
  - 傾圧不安定実験 (北野)
    - 力学コア
  - 同期回転惑星 (納多)
    - パラメータ: 自転角速度, 太陽定数
  - 水惑星 (島津)
  - 木星のような計算 (馬場)
    - レイリー摩擦
  - Held and Suarez の力学コアベンチマーク
- 長期目標
  - 地球と火星と金星の間の惑星の計算 (高橋)
    - パラメータ: 惑星半径, 1 年の長さ, 自転速度, 乾燥 or 湿潤
  - 突然昇温 (西澤)
    - ニュートン冷却
  - 「世間並み」の地球にするための過程
    - 雲, 積雲, 地表面, 放射, 植生
  - 暴走温室計算 (石渡) の再計算
  - 全球凍結計算 (石渡) の再計算
deepconv
- 短期目標
  - 木星 (杉山)
    - 3 次元化
      - コリオリ
  - 火星の乾燥対流 (小高)
    - ダストデビル
  - 火星の主成分凝結 (山下)
    - パラメータ: 臨界飽和比, 初期状態, 雲粒落下の有無, 浮力に対する荷重効果の有無
  - 地球の雲対流 (今関)
    - 現実のある日の大気構造を初期値にできる
  - 理想化された流体
    - 比熱, 分子量を任意に設定できる
  - プリュームの上昇
  - 重力流
- 長期目標
  - タイタン (中島)
  - ネスティング (中島)
  - 仮想的な惑星の雲対流
    - 任意の組成
  - 主成分凝結対流の大領域計算 (石渡)
    - 南北温度差
    - 地表面モデル
  - 木星の放射
  - 随伴モデル
    - 感度解析をするためのツール
spmodel
- 短期目標
  - 回転球殻モデルの設定を変えた計算を増やす
  - 粘性の温度, 高さ依存性が入った対流
- 長期目標
  - 平行平板 3 次元対流
  - 片方が半無限, 片方が周期境界のサンプル
  - ドキュメント, サンプルの整理
    - numexp プロジェクトで具体的問題を解いた結果を置いている
  - 非弾性 3 次元対流
  - 球面プリミティブモデル
  - Navier-Stokes モデル

必須事項の確認

dcpam
- 着手
  - モデルの中身を読み解く
  - ドキュメントの整備
  - 暦の設定
    - 1 年の長さなど
- 未着手
  - 実行速度の改善
  - 並列化
deepconv
- 着手
  - ドキュメント作成
  - 力学過程の再構築
    - 熱力学変数, 湿度変数の見直し
    - 火星, 木星モデルの統合
  - 3 次元化
  - モデルの中身を読み解く (山下, ...)
  - 実行速度の改善
    - 宇宙研で実行速度が出ない
    - 対処方法が分からない
- 未着手
  - 放射
  - 地形
  - 暦の設定
  - 力学過程の検討
    - 準圧縮方程式の可否の検討
  - 地表面過程の導入
    - f77 版の物理過程の移植
  - サンプルの同梱
    - 大学院生レベルの基本
    - プロ仕様
  - 雲微物理過程の検討
    - 混合物の凝結
    - 氷相の取り扱い
spml ライブラリ
- 並列化については実装済み
  - ispack が並列化されているものについては ispack にお任せという意味では出来ている
gtool5
- 着手
  - 暦, 時間管理
    - 1 年の長さなど
    - ほぼ完成
- 未着手
  - 現段階の製品リリース, dcpam への導入
  - 暦, 時間管理
    - 変数の出力判定関数の作成
  - ユーザマニュアル, 開発者マニュアル, 設計思想の文書
  - netCDF4 の調査
    - 並列 I/O

具体的な計算目標を実現するために必要なもの

dcpam
- 放射

今やらないと将来的に困るもの

dcpam
- 並列化
deepconv
- 3 次元化
- 力学過程の検討

dcpam

解決しようとしている問題とその対処法

物理過程モジュールの独立性を提案
- ソースの上から下まで見なくてもよい
- 並列化に耐えられるか?

コードレビュー

着脱可能だがメインプログラムを書き換えて再コンパイルしなければならない
- use 文
サブルーチン名を変えることで並行して存在できる
- モジュール名, サブルーチン名が異なることが縛り
計算方法を変えたい場合は if 文で分岐するようになっている
- namelist を変更すればよい
if 文に並べざるをえないのが弱い
- 計算方法が増えるとソースが長くなり, ソースの簡潔性が失われる
mainInit で初期化
出力は個々のサブルーチンに埋まっている
dcpam では全ての過程が main の中にある
- main だけで全容が分かるようにしたかったため
- AGCM5 では physics の中に物理過程が展開されていたので, main が短く見えた
- dynamics は過程の 1 つに過ぎない
  - 昔は dynamics が偉かったため, dynamics と physics に分けた
RDoc で生成したドキュメントに, 計算している過程などのダイジェストが載らない
- RDoc は元々ライブラリ用リファレンスマニュアル生成プログラムであるため
- 何らかのタグを我々で決めて RDoc に実装すれば, コメントをドキュメントに出力できるはず
f90 にしたのになぜ長いか (竹広)
- RDoc を使うようにしたため, コメントが長い
- 骨組みだけ抽出するツールなどで補える
水を抜きたいときにどこをいじればいいか分からない (石渡)
- 表面フラックスなどの値を全部ゼロにしたい
- 何もしないダミールーチンを作って if で囲めばいいが, それをどこに作ればいいか?
- 水の有無を切り替えるルーチンはない
  - 水は複数のモジュールに関係しているため
source, sink のある passive scaler は Q* という変数になっている
モジュールにしてあれば再利用しやすいか? (竹広)
- 似て非なる金星を作る場合
- どこのモジュールを残してどこを取り替えるべきか曖昧
- モジュール横断的な変数をいじりたい場合はモジュール別に対応しなくてはならない
  - ドキュメントを見ながらやるしかない
「火星スイッチ」は実装される予定か? (石渡)
- 物理過程は namelist 内でスイッチを変更できるので, 別 namelist を準備することで対応
- HS94, FullPhysics, NoPhysics などの標準実験は別枠にする
  - 標準実験であると同時にモデルのチェックにもなる
- どの惑星にどの過程を適用するのかは良く分かっていないので設定が不可能
- 惑星ごとに大枠を作る (HS94 のようにする) とどうなるか
  - 大枠が乱立して整理が悪い
  - 中間の惑星を計算したいときにどの大枠からスタートしてよいか迷う
速度チェック (林)
- Intel の CPU で, AGCM5 との比較
  - SX のときと同じく, 数倍も差が出るか
  - 致命的に遅いときはどう対応するか
spml の書法を使っているのでコンパクトにまとまっているが, CPU が遊びうる (堀之内)
- ボトルネックの箇所でなければよい
dynamics の最後に出力 (DiagOutput) があるのは何故か? (中島)
- 計算のルーチンと思わせて出力なのは何故か
- 中で出力のために計算する量も計算しているため
出力のために計算する量を毎ステップ計算しているのは無駄
- dynamics の最後の DiagOutput
use 文がスイッチできたら良いが, f90 ではできない
「読まないと書けない」状態からの脱却
開発者向けマニュアルがない
- 作成方針, 設計思想など

gtool

開発体制

マネージャ; 佐々木
開発者: 西澤
監督: 森川

gtdata

netcdf とは別のデータ形式
- gphys と同じことをやろうとしたのを gphys の前に豊田さんが考えていた
  - 入力データフォーマットによらない処理を実現
- 将来の開発のために残してある.
  - 例えば, netCDF3, 4 の構造の違いを隠蔽するのに使う?
data I/O については history 系にシフトした
- これだけでも一通り, データの属性を取り出せる
- ユーザは gtdata を覚える必要はない
開発者向けのドキュメント
- 「gtool5 ライブラリ概説」ページにある
開発者向けドキュメントにどう実現しているか, なぜ実現しなくてはならないか, が書かれていない
- gtdata について概念を説明したドキュメントが必要
- 何故中間のデータ形式が必要か?
  - 各データ形式用の入出力ライブラリに固有の名前を張り替える手間が省ける
例えば新しいファイル形式の入出力を実装するときにどうしたらよいか, というドキュメントがない

configure

configure を実行するまでが大変
- 長いオプションが大量に必要
configure の作り方が分からない
- 簡単な手引きがあるといい
教育的には, 自動化しすぎると学生が使えなくなる
- 自分で変更, 修正できない
世間的には, configure があるのは標準

その他のメモ

CVS に, 自動生成されるものが大量に残っている
- パッケージ化の際に別途生成するようにする
make distclean しても綺麗にならない
- depend などが残る
MPI を使うときのチュートリアルがない
gtool_history で積算平均はできない
- auto ではできる

deepconv

歴史的経緯

2008 年度末に山下プログラムを CVS に登録する際に, 似て非なるファイルが大量にあり, メンテナンス性が悪いことが分かった
- 雲粒落下を考慮する, しない場合でファイルが違っていた
- namelist 側で対応できる処理も多くありそう
火星と木星で別のモデルになっていたのもあり, arare5 として再構成したほうがよい, という結論になった
- 準圧縮方程式系の再考も行う
  - 温位が保存量でないのは気持ち悪い

現状報告

現状
- 木星・火星乾燥 (2D) で使うサブルーチン等は共有
- 3 次元化は火星乾燥で先行
  - 下回りのプログラム (微分平均演算, 境界条件) は小高さんが作成
- 火星湿潤と木星・火星乾燥で, プログラムが分離
- MPI 並列しているのは木星版だけ.
  - 他のもすぐに対応できるはずだが....
プログラム分離問題
- 火星湿潤版内で, 似て非なるファイル沢山
- 木星・火星乾燥からのコピーが古い. 最新の cvs の内容が反映されてない
  - ちょっとだけ改変しているもの有り.
- 対策は後回し.
定式化の問題
- [現状] 過去をひきづっているので, 熱力学変数が異なる.
  - 木星版: 混合比 (凝結物, 凝結成分気体)
  - 火星湿潤: 密度 (凝結物)
    - arare3 の頃の北守プログラムを移植
    - arare3 の頃は, 動くものを作ることを最優先していた?
  - arare4 になった後も 2 つで用いる熱力学変数が異なっている理由は覚えていない
    - 山下修論の完成を急いだ?

今後の作戦

開発体制変更
- モデル書き: 杉山
- テスト計算: 山下 + α
  - 週一くらいでモデルを読む
梅
- 3 次元化
- 並列化
- プログラムの体裁を dcpam と合わせる
- src-mmc (火星湿潤) との diff を調べる
竹
- 熱力学変数を比湿に統一
  - 算数的な問題が解消. 混合比で書くと主成分凝結系では値が発散する.
    - 地球・木星のような微量成分と, 火星のような主成分凝結を 1 つのプログラムで扱えるようになる.
    - 火星版と木星版を統一するために必要な処置.
  - 火星主成分計算で, 非凝結成分を考慮することができるようになる.
    - 湿潤断熱線からずれられるようになる
- テスト計算は湿潤部分のみ行えば良い (乾燥部分は済み)
松
- 温位を導入するために用いた, 比熱を定数 & 分子量を定数とした仮定を外す.
  - 山下案: T, p で定式化をやりなおす
- テスト計算を一通り行う
中島コメント
- このモデルの売りは「様々な組成が扱える」ところにあるはず将来的には「松」にしないと意味ない.

3 次元化

[現状] 乾燥版の 3 次元化は終わっている.
凝結成分の時間発展方程式を 3 次元化
凝結成分に関する物理過程モジュールを 3 次元化
3 次元で走らせる場合と 2 次元で走らせる場合のスイッチをどのように入れるか検討.

並列化

MPI 並列
CPU 毎に出て来たファイルを扱うためのドキュメントやスクリプトの整備

プログラムの体裁を dcpam に合わせる

昔の天文台でのモデルミーティングの内容を思い出す.
変数名
メインプログラムの見てくれ
gtool5 (HistoryAutoCreate) 対応
- nml の書き方
- 積算量の計算・出力に gtool5 を使う
マニュアル等の並びや置き方, Makefile や configure 等の格好
- dcpam の「コード解説」が中途半端.
  - モジュールの話が足りない
  - physics の部分が無いが....

方針

「竹」まで行う.
- dcmodel ミーティングやオフラインミーティングで定式化, 離散化, 物理過程のドキュメントチェックはどんなに遅くても夏までに行う.
- 「梅」の内容は先行して夏までには終わらせる.
「松」は一時撤退.