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