dcpam 開発コアミーティング

1. 概要
2. メンバー
3. dcpam4 (dcpam バージョン4) へのコメント
4. 今後の開発方針
5. 開発スケジュール

概要

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 の速度がどの程度か.
      • その先の目標: 遅い場合, その原因の追究.
• 〜 08/20 (天文台ミーティング)
  • dcpam5 と arare4 のコードを眺め, 擦り合わせる

dcmodel Development Group / GFD Dennou Staff
Last Updated: 2008/07/09 (森川 靖大), Since: 2008/06/26 (森川 靖大)