- 参加者
- 天文台 : 林, 中島, 石渡, 小高, 佐々木, 森川
- 北大 : 高橋, 杉山, 山田(由)
- 日時
- 12/25(月) 14:00 - 12/27(水) 12:00
- 場所
内容: 今年一年間の主要な進捗を中心に, 現状を互いに報告しあう.
- 12/25 午後
- 16:00 開始 -- 17:30 終了
- 20:00 開始 -- 22:00 終了
- 12/26(火)
- 09:00 開始 -- 13:00 終了
- 15:00 開始 -- 19:00 終了
- 21:00 開始 -- 22:00 終了
- 12/27(水)
- 午前 09:00 開始 -- 12:00 終了
- 今後の計画
- gt4f90io (森川)
- gtool4 規約 (石渡)
- コーディングルール (石渡)
- 田島さん(九大 M2) がユーザとして使用中
- 完全圧縮系の方程式を解いているモデル作成
- 積雲生成時の地表面気圧変動を見る 2D モデル
- 比熱一定 -> そのままでは他の天体には使えないけどね
- 中野さんが GMS からしょうがなく, 添字付きモデル作成 & 使用中
- 遅い: 速度は添字付き (通常の差分モデル) の 3〜 6 倍
- GMS のありがたみ -> 添字付きを作成してみて実感
- GMS の難点は変わらず = 正しい「富豪的プログラミング」
- GMS の利点: 構造体による添字の隠蔽
- 添字から解放された.
- 学生に「モデル作りな」と気軽に言える, できちゃう by 健介さん
- GMS の欠点: 遅い.
- コンパイラによる構造体の最適化がタコ -> 添字付きの 3 〜 6 倍
- 学生が「差分モデル作れる」と思っちゃうと…泣いちゃうよね.
- ドキュメントが無い
- rdoc をががっと掛けてしまえば良い?
- Debian package の rdoc-f95 を健介さんが使ってみた
- それっぽく見えるようになりました.
- コメントが正しく記入されていればコメントも表現される(素晴しい!!).
- 今後
- 修正は ispack/snpack/snt.F, ispack/ftpack/ftz.F, spml/wa_base_module.f90.
- ispack 側は SX6 用にループをアンローリング(分割)
- アーキテクチャ依存? ソースコード側で弄る所?
- -DSPLIT は効かないの?
- wa_base_module.f90 は配列宣言の入れかえ
- メモリアクセスが連続的になる様に ((nm+1)/2+nm+1)*2,km) の順に
- もともと何故 (km, (nm+1)/2+nm+1)*2) だったのだろう?
- 結果
- 速度にして 30 % の高速化
- メモリ使用量は大幅に増加(約 6 倍)
- ナニを基準値として速いとか議論するの?
- 詳細はメール参照 -> 石渡さんが整形してメールする, ハズ
- F77 版の方が速い
- 単純比較できるデータでは無いけれど…
- MOPS で 2.2 倍, MFLOPS で 3.2 倍, 計算時間で 3 倍…
- ベクトル命令数は期待される数 but 全命令数はだいぶ多い
- ftrace の結果: dynimpfunc.linsolve_lapack の BANK 衝突が異様に多い.
- 九大計算機センター提供の lapack では遅かった, という実例
- F77 版では
- deepconv/arare の MPI 並列化 by 高橋芳幸さん
- 配列添字の開始点は 1 か 0 か
- 具体例: im の長さの配列 hoge があった場合, hoge(0:im-1) なのか
hoge(1:im) とするのか. (後者は hoge(im) とも書ける).
- spml の現状
- w 系のモジュールの手続きの引数, 内部変数の配列の開始点は
1 となっている.
- ae, ee, t 系のモジュールの手続きの引数, 内部変数の配列の
開始点は 0 となっている.
- deepconv の現状
- 境界を含む配列の開始点は 0, 境界を含まない配列の開始点は 1
となっている.
- 今のところ 0 から開始にしようという話になっている
- g95 でも ifort と同様にセグメンテーションフォールが起こった
- 今後の作業としては
- とりあえず上記の配列添字問題から取り掛かるため, 原因探しは後で
- とりあえず原因探しする際の具体的作業は....
- デモプログラムおよび spml 本体に WRITE 文や STOP 文を
差し込んでどこで落ちるかを調べる.
- 生 html に残っている解説をソースコードへ移動
- 竹広さんの赤道加速弱非線形計算の非線形版をやってみる
- 異なる物理プロセスの切り替えを, 可読性を損なわず容易に行なうために.
- 例えば積雲スキームを Kuo, Emanuel, 対流調節などと切り代える場合.
- 実装案
- 第 1 段階
- ソースコード中で use 文を書き代えてモジュールを変更しコンパイルする事で行なう.
- 取り外す場合には dummy のモジュールを use 文で指定.
- 交換対象となる物理プロセスの引数の型はできるだけ揃える.%
- 必要に応じて optional 引数と 引数 keyword を使用.
- 第 2 段階
- プリプロセッサを用いて #ifdef で use 文の書き代えを機械処理
- 第 3 段階
- プリプロセッサのフラグは configure 設定する.
- Config.mk に CPPFLAGS をつけておく.
- 必要に応じてCPPFLAGS を追加 & 書き代え
- ドキュメントにも反映すべし by 石渡
- プログラム構造の変化
- サブルーチンはできるだけ使わずに配列関数で.
- 配列関数は基本的に戻り値として tendency を返すようにした
- 1 ステップ計算を実行している行が主プログラム内で見えるようにした.
- 数式中の取替えそうな項は subroutine にした方が良いかもしれない.
- 差分モデルのための微分平均計算用モジュール
来年 1 年間で何をどこまでやるか?
小高さんか石渡さんが林さんから引き継ぎ.
- 動く版を作成する路線を継続
- 物理過程等の差し替えテスト
- 現行版は木星にフォーカス -> 地球や火星でも動くようにしたい.
- 下部境界での熱および力学的境界条件の交換を簡単にできるようにする.
- 凝結過程・放射過程の着脱を簡単にできるようにする.
- 並列化
- 芳幸さんの テストを参考に, 並列モジュールの開発実験
- 3 次元化(時間があったら)
- 最下層のモジュールの雛形は完成 -> 2D, 3D を同じ枠組みで作成する.
- 計算計画
- 木星大領域計算: 杉山さん -> 並列化が進む?
- 火星凝結計算: 小高さん -> 物理過程等の着脱の簡単化が進む?
- 地球積雲対流計算: 中島さん
- 現在用意されている資源(spmodel, gt4f90io, コーディングルール)で動く版を作成する.
- セミインプリシット化
- パラメタスタディ(木星モドキ: 自転角速度, 半径, 重力, 大気圧など)
- 物理過程モジュールの整備
- データ I/O について森川さんより以下の提案がなされたが, 保留.
データ I/O を階層化し, gt4f90io をきちんと使うようにする
(上層) 演算 <- gphys チックな構造体 <- gt4f90io (下層)
^^^^^^^^^^^^^^^^^^^^
↑ここを 作成する.
history 等を定義する構造体 ?
演算部分で
構造体ごと演算部分で使うか
数値を取り出して持っておくか
出力する or しない変数の区別は?- 階層モデル群全体が幸せになれるだろうか?
- メインプログラムの顔付きはどうなるか?
- 構造体とそれに対する手続きが全部用意されたとして.
- とりあえず動く版(現行版の I/O 書式)を作成し, 計算実行し, ユーザにとって望ましいプログラムの構造と書法とはどんなモノか, について経験を積む必要があるだろう.
- 配列添字問題
- これが終わったら
- ee_module の yx_ 問題については保留
- et_diff1.f90 のセグフォは気が向いたら
- ドキュメントの不備は気がついたら.
- 3d-shell-wt/ 球殻対流計算
- 計算は北大 SR11000(今年度) と天文台のカテゴリ C(来年度?)
- 現状固定
- 小物は必要に応じて増えるかも(dc_date 等).