dcpam 開発コアミーティング
概要
6/26 (木) に, 以下のメンバー (中心は石渡, 森川, 高橋) で行った dcpam 開発に関するコアミーティング (ソースコードの読み合わせと, 今後の開発方針, スケジュールの相談) についてのメモ書きである.
メンバー
- 神大: 石渡, 森川, 高橋, 佐々木, 納多, 林
- 九大: 中島
- 国立天文台: 杉山
(敬称略)
dcpam4 (dcpam バージョン4) へのコメント
重複する部分もありますこと, ご容赦ください.
- プログラムの全体構造が分かりにくい
- 初期設定ルーチンが何をしているのか分からない
- モジュールの独立性を意識しすぎ, 従来のモデルでは, モデル全体について一箇所で行っていたチェックを 各モジュールで独自に行っている. 結果として, 読み手が知りたい情報が チェックのためのソースコードに埋もれてしまう.
- 構造体の使用され方が分からない
- 構造体に各モジュールで計算に必要なパラメタを格納し, その構造体 を主プログラムで持ち運ぶという概念自体が, 誰かが横からコメント を入れないと分からない (=> ソースコードを読むだけで分かる, という理念に反する).
- 初期設定ルーチンが何をしているのか分からない
- 計算の前処理に関するコードが長すぎる
(= ソースコードの上部に出すぎている)
- その結果, いわゆる計算部分に関するコードが埋もれてしまう (= 探し出すまでに時間がかかる)
- 想定するユーザの大半はオブジェクト指向的な概念に馴染んでいないため,
例えば, 「初期設定ルーチンでオブジェクトに対して設定値を与える」など
のことがソースコードを読んだだけではイメージできない (= すなわち読めない)
- つまりはソースコードの書き換え (パラメータを足したり引いたり) もできない.
- 各モジュールの独立性を重視しすぎたあまり, 各モジュールの
初期設定ルーチンに同じようなコードが多数存在するようになっている.
- 結局「同じソースコードの2度書き」になってしまっている.
- 「継承」の機能があればよりシンプルに書ける (コードを一箇所にま とめられる) かもしれないが, Fortran 90/95 の言語規格では困難.
- リスタートファイルの入出力やヒストリファイル出力のためのソースコード が主プログラムに陽に書かれており, 主プログラムを読みづらくしている.
- 定数管理モジュールがあってしかるべき (この方が結局「この定数をいじるにはどこ見ればいいかな」が分かりやすい).
- データ I/O について
- 問題点
- モジュール毎にデータ I/O の管理について独立管理してみたものの, 結局モデルのソースコードのあちこち (各モジュール毎に一つ) の HistoryCreate を書き換えるのはやはり面倒.
「出力する変数を増やしたい」という場合に, コピペする部分が (それなりに少なくしようとして入るものの) やはり多い. AGCM5 などのように, 変数登録には
| CALL HISTRG !" 出力の登録 | I ( 'U ', 'u-velocity ' ,'m/s ', 'ALEV', | I VMISS, VMISS, DIVSX, DIVLX, ISTYPL, | I ' ' , ' ' , 0 , 0 , 'X' ,'(F12.3)' )
出力には
CALL HISTIN ( GBU , 'U' ) !" 出力データの記憶
を呼ぶだけになっているのが望ましい. なお, 他のあるモデルのように HISTRG についてはヒストリデータ出力のためのモジュール内で 登録を行うようになっていても良いのかもしれない.
- 問題点
- テストプログラムについて
- モジュール単体毎にテストプログラムを作成し, make test などで 一発チェックする, というテストシステムの整備コストが (gt4f90io ライブラリの dc_test モジュールによってそこそこ 手間の簡素化を図りはしたものの) モデル利用者 (モデルインフラの 開発や維持をメインとする人ではないという意味での「利用者」) にとって, 効果に結びつかない (さほどうれしいと感じない) のではないか.
- しかし, 上記で言う「利用者」にとってのコスト対効果の評価をおいてお けば, 一般論として, 大規模化に比例して (あるいは指数関数的に比例し て) テストをきちんと行うことは重要. モデルの部品の精度, あるいは 他人の作った道具の信頼度の向上に役立つ.
- 主プログラムに陽に記述されている風速⇔渦度発散の変換に関するコード は力学過程の演算モジュール内に内包されているべき.
- 並列化について
- 力学過程は MPI 版の SPMODEL が近日公開予定なので, それを使用する.
- 物理過程と入出力についても要考慮. 上記の問題点を解決した dcpam を早急に改装し, なるべく早い段階に並列化に着手する.
- 引数キーワードが鬱陶しい
- optional 引数など, 必要なもの以外は書かない方が文字数が少なくて 読みやすい.
今後の開発方針
- 計算の前処理はなるべくソースコードはなるべくファイルの下部に記述する. 一方で演算に関するソースコードは上部に記述し, ファイルを読み始めた人 がすぐに演算に関するコードを読めるようにする.
- パラメータを引数に渡すのは止め, 定数参照型モジュールで 管理するようにする.
- モジュール内で保持する設定値の保存には構造体は使用せず, SAVE 属性の変数を使用する.
- dcpam3 や arare4 に存在する格子点数設定モジュール, 軸データ設定モジュールを用意する.
- 各モジュール毎にテストプログラムを用意するための「やり方 (作法)」 を取り決める. その具体例として, いくつかのテストプログラムを 作成しておく.
- リスタートの入出力は主プログラムでは行わず, 別途モジュールを作成してそちらで行う.
- ヒストリデータ出力 について
- 以下のような特徴を持つヒストリ出力用のモジュールを用意する.
- AGCM5 のように「出力の登録」と「データの出力」を行うための 手続きを用意する.
- 出力間隔や出力ファイルなどの情報を NAMELIST から読み込み.
- HistoryCreate や HistoryAddVariable などは,
NAMELIST の読み込みなどのブラックボックス的で良い部分と
なるべく切り離し, これらのサブルーチン呼び出し部分のコードは
ユーザが読める and 簡単に書き換えられるように実装する.
これは, dcpam と arare とで同様なヒストリ出力用
モジュールを使用できるようにするためである.
- (本日の議論より) 原理的には, 「出力変数を一つだけ足す」際には, HistoryCreate やいくつかの HistoryAddVarible を一揃え書き足す (元々あった変数出力のコードをコピペする) だけでよい. それで gt4f90io を用いた書式で統一されてグッドではある. しかし, この方法では実際には, 一変数毎に 50 〜 100 行の ソースコードのコピペをする必要があり, 結局面倒. また NAMELIST から出力間隔やファイルを変更するのも困難.
- 以下のような特徴を持つヒストリ出力用のモジュールを用意する.
- 主プログラムで風速⇔渦度発散を計算するのではなく, 力学計算に風速を与えて計算できるように.
- 原則的に, optional 引数などで必要な場合以外は書かない
開発スケジュール
- 〜 07/09
- プログラムの顔つきを見るべく, 以下のものに関して
「こんな顔つきになるはず」というプログラム (ハリボテ) を作る. (森川)
- データ出力は実際にできていなくて良い.
- コンパイルができない段階でも, 形ができたら報告する.
- 作成するファイル
- メインプログラム
- 定数設定モジュール
- いくつかの演算モジュール
- 放射過程
- 乱流拡散
- 積雲パラメタリゼーション
- 上記のプログラムに関して, コメントをいれる (石渡, 高橋, 小高, 杉山, 中島)
- プログラムの顔つきを見るべく, 以下のものに関して
「こんな顔つきになるはず」というプログラム (ハリボテ) を作る. (森川)
- 〜 07/16
- ヒストリデータ出力モジュールの作成 (森川)
- ヒストリデータ出力モジュールの arare への移植
- 移植作業 (森川)
- 使い物になるかチェック (小高, 杉山)
- 〜 07/23
- 力学過程の作成 (森川)
- 〜 08/17 (天文台ミーティングまで)
- dcpam4 に実装されていた物理過程を一通り実装 (森川)
- 実行速度のチェック (森川)
- AGCM5 と比べてどこが遅いのか?? なぜ遅いのか??
- 最低限の目標: AGCM5 に比べ, dcpam5 の速度がどの程度か.
- その先の目標: 遅い場合, その原因の追究.
- AGCM5 と比べてどこが遅いのか?? なぜ遅いのか??
- 〜 08/20 (天文台ミーティング)
- dcpam5 と arare4 のコードを眺め, 擦り合わせる