電脳モデルミーティング 2007

• 日時: 2007/12/26
• 場所: 国立天文台三鷹キャンパス, 北大, 神戸大
• 参加者:
  • 天文台: 林, 森川, 佐々木, 石渡, 小高, 中島, 杉山
  • 北大: 山下, 徳永
  • 神戸: 高橋

スケジュール

• 12/26 午前 (09:00 - 12:30)
  • スケジュール確認
  • 懸案事項についての検討
    • gtool4 規約
      • 現状と, 今後どうするかといった確認
    • プログラム書法の検討
      • dcpam と deepconv でのソースコードの見た目, プログラム構造の違いを確認
      • 確認する項目の例
        • モジュールの設計方法
        • 関数, サブルーチンの命名方法
• 12/26 午後 その 1 (14:30 - 18:30)
  • 引続き議論
• 12/26 午後 その 2 (21:00 - 22:00)
  • 今後の確認, 来年度の開発計画

懸案事項の確認と検討

gtool4 規約

• 現状認識
  • 2007/12/12 の dcmodel ミーティングメモ を参照
  • CF 規約が業界標準となっていくだろう, なのでそれに準拠するのが良い
  • CF 規約に準拠した我々のための規約は欲しい
    • CF には必須属性がない, 推奨属性だけ
• gtool4 規約を今後どうするか
  • CF 規約に準拠した GFD ユーザのための規約とする
    • 最低限必須属性, 属性値の記入方法
  • CF 規約と同じ意味を持つ属性で, 異なる名前を持つものは CF 規約にそろえる
• モデル開発にあたっての注意事項
  • CF 規約の Standard Name Table で指定されている名前のうち, そのまま使用してもさしつかえないものであれば, それを standard name 属性値として用いる
  • ただし, Standard Name Table とつきあっていくには注意が必要
    • どんどん地球に特化した名前が増えていくことになると予想される. すでに "air_temperature" "sea_water_temperature" などの名前がリストされている.
    • 我々が無批判に付き合って行くと "Mars air temperature" などという名前を付けていくのか, 大気と海洋の区別がつかない木星の場合はどうするのか, という問題が生じる. そのような場合は standard name 属性を使用しない, ということになるだろう.
    • spmodel のような抽象的なモデルの場合には, standard name 属性を使用しないのが正しい.
• ToDo (石渡)
  • CF 規約の White paper のチェック
  • CF 規約の bounds 属性の調査
    • gt_calc_weight の代替になり得るか? など

プログラム書法

• Fortran90 の関数の使い方
  • 以下の Fortran90 の関数の使い方について dcmodel プログラミングガイドに加筆する.
    • Fortran90 の関数の仮引数の授受特性は in とする.
      • コンパイラによっては, 仮引数の授受特性を inout, または out にすることができるため

dcpam と deepconv のプログラム比較

• deepconv
  • コメント
    • サブルーチンの仮引数に対する授受特性のコメントがない
  • ファイルの I/O
    • gt4_history のサブルーチンを call するラッパーモジュールを用意している
    • メインプログラム内に gt4_history のサブルーチンがずらずら並ぶのがいやだったため, メインプログラムから分けた.
• dcpam
  • ファイルの I/O
    • メインプログラムで予報変数とリスタート用を出力するための gt4_history のサブルーチンを直接 call している
    • 各モジュール(力学コア, 物理過程)の内部でも I/O を行っている
      • モジュールを着脱したときに I/O まわりをできるだけいじらないようにするため
      • gt4_history のサブルーチンがメインプログラムにずらーっと並んでいて, 読みづらい. 多少整理して読みやすくすることは可能.
• I/O 部分のプログラムの書き方
  • 問題点: メインプログラム内の I/O 関連のサブルーチン call などを記述した部分が長くなってしまう
  • 現状
    • deepconv: メインプログラムで call していた I/O 関連サブルーチンをモジュール化して別ファイルにまとめた
      • 当初はメインプログラムのサブセットだったはずが, メインプログラムで参照されていない変数を出力するようになっている. モデルの各パーツの着脱の妨げになっている.
    • dcpam: 出力する変数が参照されている場所で I/O 関連サブルーチンを call する.
      • メインプログラムで参照されている変数はメインプログラム内で出力
      • モジュールで参照されている変数はモジュール内で出力
      • メインプログラムが読む気が失せるくらい長い, 時間積分ループになかなかたどりつけない, という問題がある
  • 今後の対策
    • 基本方針: メインプログラムで出力するのはメインプログラムで参照されている変数だけにする. モジュールで参照されている変数はモジュール内で出力するようにする.
      • dcpam 方式を採用
      • メインプログラムの I/O の基本設定に関するサブルーチン call 部分は内部サブルーチンにまとめる.
        • 内部サブルーチンの場合は call しているプログラム内において, 内部サブルーチンであることを明記する.
• dcpam4 におけるモジュール設計
  • モジュールで初期化の際に値が確定される変数は, 構造体に定義されている要素に格納する.
  • 構造体変数の初期化, 参照, 代入を行う手続きの名前は 統一する
  • use 文で参照するのは手続きと型のみ. モジュール内で 定義した変数・定数を参照する場合は, 参照手続きを介 して行う. 直接参照, 代入はダメ
  • コメント
    • 可変性は確保できるかもしれないが, 可読性は下がっているように見える
      • 情報隠蔽しすぎて読みにくい(?) 構造体の要素を定義したモジュールまでたどって いかないと, コードを読んでも何をやっているか わかった気がしない
      • 情報隠蔽が不十分で読みにくい(?)
    • 実際に計算を行っている部分にたどり着くまで時間が かかる.
    • 初期化などの手続き名がどのモジュールでも同じ なので, 手続きを定義しているモジュールを発見 するのに手間がかかる.
      • たとえば phy_ape.f90 内において, たくさん call されている Create がどのモジュールで 定義されているのかわからない,
      • 手続きの命名を工夫するだけでかなり改善できる かもしれない.
        • たとえば, 湿潤過程(積雲)の初期化手続きは CreateCumulus など, 機能を反映しつつ固有名詞をふくまない ような手続き名にする.
• dcpam4 におけるプログラム雛型ファイルの作成方法
  • Ruby スクリプトで自動的に生成する
    • dcmodel_f90sample_maker.rb
    • f90 モジュール, テストプログラム, NAMELIST ファイル,シェルスクリプト が作成される
  • コメント
    • 出力変数を増やす場合にどこからどこまでをコピー ペーストすればよいのか, すぐにはわからない
      • 単に変数出力するだけのことをやっているはず なのだが, 何故か読みにくい
      • 出力部分以外は内部サブルーンにすると読みやすなる?
    • 雛型を用意して書き換えるスタイルに慣れていない.
    • 可変性は確保できるかもしれないが, 可読性は下がって いるように見える
      • 対応策はありそうだが, これで OK という案は 現時点では思い付かない.
• deepconv における物性値の取扱方法
  • とりあえずソースコードを眺めた
    • モデル内では以下のパラメータの値を保持している
      • 基準状態のエントロピー
      • 基準状態のエンタルピー
      • 温度の関数としての比熱の値を格納したテーブル
  • 検討すべき課題
    • deepconv で用いている方法は dcpam でも使えるか? 使えるようにするにはどうしたらよいか?