2008/06/25 の dcmodel ネットミーティングのメモ書き

参加者

  • 神戸
    • 林 祥介, 高橋 芳幸, 森川 靖大, 佐々木 洋平
  • 北大
    • 石渡 正樹, 山下 達也, 小高 正嗣
  • 国立天文台
    • 杉山 耕一朗
  • 九州大学

    • 中島 健介

    (順不同, 敬称略)

次回日程

  • 日時
    • 07 月 09 日(水) 14:00 -
  • 場所
    • 神戸大 : 自然科学 3 号館 508
    • 北大 : 理学部 8 号館コスモスタジオ
    • 九大 : 理学部 3 号館 3605
    • (国立天文台 : 杉山居室)

引用例で挙げられるプロジェクト名がページによって異なっている問題

  • TODO
    • dcmodel プロジェクトと gtool4 プロジェクトの中身の整理 (石渡) 各項目の不整合を整理する.
    • プロジェクト全体の引用の仕方の例は

      地球流体電脳倶楽部 hogehoge プロジェクト, year:URL,
      地球流体電脳倶楽部

      とする. この例にならっていない gtool4 規約, deepconv プロジェクトの引用例を 修正すること. (石渡)

    • 引用の仕方の例における year をどのように書くかちゃんと すり合わせしておいた方が良いかもしれない.

DCPAM プロジェクト活動報告

DCPAM プロジェクトの Web ページ整備 (森川)

dcpam4 の問題

dcpam4 モデル開発 (森川)

  • 3 月末の木星を念頭に置いた予備的実験を行った段階のソースコードをリリース.
  • ToDo
    • 降水量などの時間平均値を出力できるように修正を行う.
    • 乾燥大気の平均分子量をモデルに対し与えるようにし, 気体定数などはその値から自動に求まるようにする (水蒸気などに対しても同様).

dcpam4 のモデルドキュメント作成 (森川, 納多, 石渡)

  • 数理ドキュメント, 離散化ドキュメント
    • 現状: AGCM5 からコピーしただけ
    • 目標:
      • dcpam4 の実装に合わせたドキュメントを作成する.
      • ドキュメントの並べ方, 書き方を考える.
        • モデルの変更に対応して, ドキュメントの変更や追加が簡単に行えることを目指す.
        • 当面の作戦
          • 現在の「数理ドキュメント」, 「離散化ドキュメント」という枠をはずし, 個々の力学過程, 物理過程毎にパッケージングする.
          • ただし, 支配方程式の実装部分と支配方程式の導出な部分 (チュートリアル) の部分は分割する.
    • 作業担当
      • ドキュメントの整備 (森川)
        • まずは力学過程から取り掛かる.
      • ドキュメントのチェック (納多, 石渡)
    • 備考
      • rikigaku.tex など日本語に基づくファイル名を dynamics.tex などに変更する.
      • 数理ドキュメントは dcpam のコードに合わせた式にする. (dcpam は U = u cos φ を使ってない, とか).
        • 力学過程に関して一部修正を始めている.
        • 但し今はモデルを一旦固定するのを優先し, それが終わり次第ドキュメントの見直しに入る.
  • コード解説
    • AGCM5 の『コード解説』を dcpam 用に書き換えて 移植する. ディレクトリ名は code_description (仮).
  • チュートリアル
    • ソースコードを直接いじらないレベルのユーザ用ドキュメント 『ごくらく DCPAM』の作成
    • ソースコードをいじるレベルのユーザ用ドキュメント 『らくらく DCPAM』の作成
    • とりあえず納多がやってみる
      • 先ずは動かしてみるところから.

dcpam4 による実験 (森川)

水惑星実験で AGCM5 と比較

  • dcpam4 が AGCM5 と同様に水惑星の計算を行い, 動作を確認する.
  • その前に, 地球以外の惑星での計算に向けて, 方程式系の チェックと見直しを行う.
  • 計算設定
    • SX を用いて, AGCM5 と dcpam4 とを同じ設定で動かし, 結果と実行速度を比較する.
      • まずは並列化でジタバタする前に, シングル CPU で動かす.
    • 積雲パラメタリゼーションとして 対流調節スキームを用いる. (AGCM5 では Mkinclude を編集して nonstd/p2cuma.F を用いるようにする).
    • 解像度は T21L16
    • 積分時間は 500 日
    • Δt は AGCM5 と dcpam4 とで同じにする
    • セミインプリシットスキームを使う
    • ヒストリデータの出力間隔は 0-100 日, 450-500 日に関しては 1 日おき, その他は 10 日おき. データは /GFD_Dennou_Work[3]/morikawa 以下に置く.
    • 出力変数は
      • 東西風, 南北風, 温度, 鉛直流(ソースコード要変更), 比湿, 加熱率分布 (DLscTempDt + DLscTempDt, DRadLTempDt, DRadSTempDt), 降水量 (Rain), 蒸発量 (DVerdiffQVapDt), 放射 (RadLFlux, RAdSFlux), 顕熱 (DVerdiffTempDt), 負の水蒸気除去量 (DNegQVapDt)
  • 計算結果
    • お絵かき
      • 全球平均の図はまとめて上部に
    • 計算速度のチェック中 (環境研 SX8 にて).
      • プロファイラによるチェック中.
        • 速度は AGCM5 の 1/4 ぐらいだった(原因調査中)

木星を念頭においた仮想惑星計算

  • 下記の計算を試みたが, そもそも乾燥対流調節, 湿潤対流調節など, 地球大気を想定した方程式を計算しており, 木星大気への応用がそもそも 可能かが怪しい.
    • この機会に方程式系を一度全て見直すと共に, 欠けている ドキュメントも作成する
    • 具体的な作戦は, 見直しが終わった段階で再考する.
  • 計算設定の詳細
    • 設定に関しては Sugiyama et al. (2008) ながれマルチメディア (投稿予定) を参考にする.
    • 半径は地球と同じ
    • 自転角速度は地球と同じ
    • 重力は Sugiyama et al. (2008) と同じく 23.1 [m s-2]
    • 乾燥大気の組成は Sugiyama et al. (2008) と同じ
      • 乾燥大気の定圧比熱 : 11900.9264 [J kg-1 K-1]
      • 乾燥大気の気体定数 : 3611.44466 [J kg-1 K-1]
      • 乾燥大気の平均分子量 : 2.3053533e-3 [kg mol-1]
        • He の分子量と割合 : 4.002602e-3 [kg mol-1], 0.1455
        • H2 の分子量と割合 : 1.00794e-3 * 2 [kg mol-1], 0.8531
    • 凝結成分は水のみ
      • 水蒸気の乾燥大気に対する分子量比 : 7.8250532
    • 初期値
      • 風速: 0 [m s-1]
      • 地表面気圧: 3.0e+6 [Pa]
      • 温度: σ=1 で 490 [K] とし, 気圧 1.0e+4 [Pa] となる高度まで, 温位一定で (乾燥断熱線に沿って) 高度に伴い温度を減少させる. 気圧 1.0e+4 [Pa] 以下の高度では温度一定とする.
      • 比湿: σ=1 で 6.11641e-3 [kg kg-1] とし, 比湿が飽和比湿の 75 % となる高度までは一定とする. その高度以上では, 比湿を飽和比湿の 75 % とする.
    • Sugiyama et al. (2008)と同じく, 2.0e5 [Pa] 〜 1.0e-4 [Pa] まで, 放射を模した一様冷却を与える. 冷却率は - 1.0 / 86400 [K s-1] とする.
    • Sugiyama et al. (2008) を模して大気上部でスポンジ層を入れるべく. 1.0e-4 [Pa] よりも上層では, 東西平均値に近づけるレイリー摩擦 (時定数は 86400 [s]) を与える.
      • Sugiyama et al. (2008) では CReSS ユーザーガイド 第2版 (6.188) と同様に レイリー摩擦を与えている. 本来は dcpam も同様に滑らかな 強制を与えるべき (ただし, E-folding time はモデルのタイムステップ に合わせて大きくする必要がある).
    • 境界条件
      • 地表面運動量・熱・水蒸気フラックスはゼロ.
      • 最下層中間 (σ=0.8987071) の温度を 490.0 * 0.8987071 ** ( 乾燥大気の気体定数 / 乾燥大気の定圧比熱 ) ≒ 474.374 [K] に固定.
      • 最下層中間 (σ=0.8987071) の比湿を 6.11641e-3 に固定.
    • 水平拡散は, 最大波数の波に対して E-folding time 10800.0 [s]. 超粘性の次数は 8.
  • 降水の扱いに注意
    • Sugiyama et al. (2008) では雲の微物理過程も考慮されているが, AGCM5 や dcpam4 では雨になったものは即座に除去されるという違いがある.
    • 従って, 下層で雨が蒸発することをいずれは考える必要がある. 木星の場合, 下層における雨の蒸発が循環を駆動するということが 結構効いていそうだから.

さらにその後の実験リスト (主に dcpam4 の動作試験としてのもの)

  • 水惑星実験で AGCM5 と結果を比較する
    • 東西平均場の比較
      • 東西風, 南北風, 温度, 温位, 鉛直流, 比湿, 加熱率分布, 降水量, 蒸発量, 放射, 顕熱
    • 全球収支の比較
      • 質量 (地表面気圧), 水 (降水量, 蒸発量), エネルギー (放射, 凝結)
    • 波の活動度
      • Held and Suarez (1994) の Fig3, Fig4 を参照のこと.
      • 赤道の x-t ダイアグラム
  • Held and Suarez (1994) の論文に載っている絵と同じもの を書いてみて波の活動度を調べるについて調べる.
  • 地形を入れて計算してみる.
    • 余田グループの業績をチェックする.
    • Held and Suarez に地形を入れた計算を行った論文があるかも.
      • 高橋さんの調査では発見できなかった. 存在するかどうか もう少し調査が必要.
  • それっぽい地球を動かす
    • 観測に基づく SST
    • 地形がある
    • 陸面過程がある
    • 水蒸気, オゾン, 二酸化炭素の吸収射出を考慮した簡単放射
      • 雲の放射も適当に考慮できるとよいだろう

gtool4 netCDF 規約の CF 規約に対する位置づけに関して (石渡)

gtool4 netCDF 規約再検討北大メンバーミーティング ( 1, 2, 3 ) にて議論が中途半端になっている, gtool4 規約の今後について一応の方針を ちゃんと決める.

なお, 最近 (とはいえ既に昨年秋だが), CF 規約の White paper が公開されており, CF 規約のホームページ も新しくなっている. これらをチェックすべきかどうかも要検討.

現在, CF 規約の bounds について調査開始 (gt_calc_weight の代替になり得 るか? など)

gt4f90io 関連

dc_date で 1 秒より小さい時間を取り扱えない問題

1 秒より小さい時間は, 足し合わせていくと丸め誤差が溜まって, どんどんずれていってしまう.

ちょっと試行錯誤して何とか取り扱えるよう試みてみる (森川)

dcrtm

  • 報告事項
    • Appleby and Hogan (1984) 読書ノート作成中(徳永)
  • Todo:
    • 大気放射関連の理論マニュアルがあるかどうか確認(徳永)
    • 読書ノートのチェックを定期的に行う.
  • 覚書
    • データが集まった時点で, 何種類の吸収成分気体(バンド) を考慮すべきか, 検討する
      • まずは可能な限り考慮する, でよいが, とある時点でバンドの 取捨選択をしないとたぶん計算できないモデルになってしまうだろう.
    • Appleby and Hogan (1984) を光田放射スキームで再計算する. その際, 放射のインターフェース (deepconv や dcpam などの メインプログラムとのデータのやり取りの仕方) の検討を行う.

deepconv

  • 今後の開発の方針
    • 並列化・3D 版コードの作成を優先して行う
      • 並列化は 2D 版コードで開始, 天文台の計算機を積極的に利用(杉山)
      • 3D 版コードの作成(小高)
      • 主成分凝結過程モジュールの 2D 版コードへの移植(山下)
    • プログラムの構造・変数名・モジュール名に関する問題は後回し
      • 2D 版, 3D 版のソースコードの整理・統合は当面行わない
      • 現在の arare4 におけるプログラム構造・変数名・モジュール名を (可能な限り) 保持したまま, 地球, 火星, 木星等の大気の計算を行えるところまでコードを作成する. その過程で, 現状でのプログラム構造等の問題点も探る.
  • arare4 への主成分凝結モジュールの実装(山下)
    • 実装作業を継続中
    • 今後の予定・課題
      • 意味のある計算ができるようにプログラムを書き換える.
        • 時間発展方程式を主成分凝結系用に書き換える
        • main プログラム別個に用意する
        • 書き換え箇所を小高さんと一緒確認
      • モジュール名(cloudset)は変更せず, /src/moist/ に置くことにする
        • /src/moist/ 以下のモジュールを整理するときにモジュール名と置き 場所を再検討する.
  • arare3 を用いた北守修論の再計算(山下)
    • 北守さんの結果と比較できるように, 鉛直分布の図を追加
  • 3 次元化 (小高)
    • Odaka et al. (1998) の設定を与えた火星乾燥対流の計算を継続中
      • 1.5 次クロージャの乱流モデルを 3D 版コードに導入中
        • バグのチェック作業中
  • インストール手引きの改訂 (小高)
    • 山下が arare4 を動かし始めたら行う
    • ifc9.0 で動作させるために必要なソースコードの改変箇所を記述した

      手引の作成
  • 地形に沿った座標系の定式化ノートの作成 (山下, 石渡)
    • 時間を見つけて修正する
  • 関数名の変更についての覚書
    • 半格子<->格子の変換を行う関数に含まれる文字列 avr はとる.
    • Average モジュールは破棄. 3D 版と書法をそろえた xz_base_module を 2D 版で 使うようにする.
      • 理由は, 半格子<->格子の変換を行う関数(例 : xz_avr_pz) および, そのモジュ ールの名前 (Average) が良くないため. avr だと領域全体の平均操作を行う関数のように見えてしまう.
  • ifc9.0 でコンパイル時に生じたエラーへの対処の覚書
    • エラーを起こしたプログラム/モジュール
      • xyz_bc_module
      • xyz_module
      • xyz_deriv_module
      • xyz_deriv_c4_module
      • gridset_3d
      • chemdata
    • エラーは, use 文内で rename を用いている場所と, 引用した module の公開要素をカスケード公開している場所 で生じている
    • とりあえず, カスケード公開している公開要素は, 最初にその要素 が定義されているモジュールから直接引用するようにして, エラーを回避した.
    • 対策:
      • ソースコードレベルでは対応しない
      • ifc9.0 で動作させるために必要なソースコードの改変箇所を記述した 手引を別途用意しておく
  • 凝結成分の種類をもう少し簡単に変更できるように改良を始めた. (小高)
    • 現在中断中
    • 目標は地球版よ木星版の実行プログラムをプリプロセッサを使って単一のメイン プログラムから作成すること
    • NH4SH の反応に関係するサブルーチンの整理を始めた
  • 並列化 (小高)
  • TODO
    • 小高さんが復帰してから確認すべきこと
      • arare4 の 3 次元版で並列化の計算を行うための算段はどうなっていたか?
      • arare4 の 2 次元版と 3 次元版の管理はどのように行うことにしていたか? 2 次元版と 3 次元版でソースコードの共通化を行うことにしていたっけ?

dcmodel コーディングルールの修正

「リスタートファイルとヒストリーファイル」の 「ヒストリーファイル」に以下の記述を追記 (石渡)

平均値を計算する際に座標重みを必要とする数値データの場合には, 座標重
みのデータも各ヒストリーファイルに格納することを推奨する.

この際, 実際に netCDF ファイルにどのように座標重みを格納するかについても 記述する. これに伴い, これまでの gtool4 規約において gt_calc_weight として 使用されていた座標重み指定のための属性を CF 規約 bounds に置き換えることが 可能かどうかを調査する. (石渡)

各モデルの「チュートリアル」について

  • モデル本体に付属する, インストールから実行 (および簡単な実験) までの流れを記したチュートリアルは, 今のところモデルごとに 見た目 (名称や対象とするユーザ) が異なるため, 今後どのように 揃えるべきか要検討.

初期値生成コードの管理について

  • 下記の文書を dcpam4 の らくらく dcpam4 に移植. (森川)
  • ToDo
    • 文書に関してチェック
  • 長期 RUN 用実行プログラムは「お試し Run」できるように, 内部で 初期値を生成できるようにしておく.
  • 本当に数値実験を行う際にわざわざ長期 RUN 用実行プログラムを改変 しなくて済むよう, 初期値生成用実行プログラムは別途用意しておく.
  • ただし完全に別々に RUN 用ファイルと, 初期値生成用ファイルを メンテナンスする場合, 実際に初期値を生成するコードを「2 度書き」 せねばならず, 開発者のストレスが溜まる (deepconv 開発の経験)
  • 現状の折衷案 (とりあえずこれを dcpam4 に実装)
    • 初期値生成「モジュール」を用意し, 実際に初期値を生成するコードは そのモジュールでくるんでおく. 別途, 初期値生成のみのための実行プログラム, 長期 RUN 用実行プログラムは用意する. それらの実行プログラムは初期値 生成モジュールを参照し, データを作成する.

      ┌─ initital_data.f90 ─────────────────
      |
      |  module initial_data
      |  
      |    subroutine InitialDataCreate( ....)
      |    
      |      初期値生成コード
      |      
      |    end subroutine InitialDataCreate
      |    
      |
      |  end module initial_data
      |
      └──────────────────
      
      ┌─ init_sample.f90 ─────────────────
      |
      |  program init
      |    use initial_data
      |    
      |    call InitialDataCreate(...)
      |    
      |  end program init
      |
      └──────────────────
    • RUN 用プログラムは「おためし RUN」可能なように, 初期値生成モジュールを use してサブルーチンを実行する.

      結果的に, 「おためし RUN」の際には, RUN 用ファイルは一度初期値ファ イルを書き出し, それを実行ファイルで読み込むことになる.

      ┌─ run.f90 ─────────────────
      |
      |  program run
      |    use initial_data
      |    
      |    call InitialDataCreate(...)
      |    
      |    
      |    do ....
      |    
      |      長期 RUN
      |    
      |    end do
      |    
      |  end program run
      |
      └──────────────────

spml(佐々木)

  • spml における配列添字を 1 からではなく 0 から始めることへの修正
    • trank へマージ中
      • 合わせてドキュメントをrdoc 化, インストールドキュメントを整備
    • sample プログラムの修正については今後行う
    • この修正に関する詳細については 天文台モデルミーティングログ 2006/12/25-27 を参照のこと.

電脳 debian パッケージの公開方法について

stable, testing などではなく, sarge, etch などとする

  • 作業報告
  • TODO
    • 各地の Debian パッケージによるインストール手引きにおいて stable と記述されているものを すべてコードネーム etch (または sarge) に変更する.
      • fortran 版の dcl(佐々木)
      • spml(佐々木)

etch 版の Release.gpg に登録される鍵の共有化

  • 現状
    • 佐々木個人の鍵が登録されている.
    • パッケージリストの更新は cc-env グループであれば可能だが, Release.gpg の更新は佐々木本人でなければできない (ただし現在は cron で 1 日 2 回更新している)
  • 改正案
    • cc-env グループに入っているメンバーなら誰でもパッケージリストが更新で きるようにする
  • 具体案を dcdvlop に提示する(佐々木)

モデル開発してて面倒と感じることいろいろ

以下の, 日頃作業する際に調べる面倒だなぁ, と思う事柄に関して, dcmodel のページから 1 ホップぐらいで手繰れるところに, 必要最低限の資料を作成 する. (杉山)

  • cvs commit が面倒
    • (面倒) コマンドをすっかり忘れているので, わざわざいちいち調べなけ ればならない (コミットするのが億劫になる). 調べる情報も dcmodel プロジェクトの奥のほうにあったりして調べる作業も鬱陶しい.
      • 調べるものの例
        • cvs のタグの貼り方どうだっけ??
        • cvs のコミットどうするんだっけ?? なんかルールもあったような??
    • (対応策) 杉山氏が, 自分で cvs コミットの際に必要な情報を dcmodel ページの上の方 (検索しやすい位置) に作ってみる.
  • ソースの公開版の更新が面倒
    • 作業そのものはだいぶ簡素化されている (タグが書き込まれているファイル を書き換え, あるディレクトリで make するだけ).
    • やり方が流布されれば OK ??
  • gt4f90io の開発についていけない
    • (面倒) なんかいろいろ開発してるらしいが, ついていけん.
    • 時間が取れるときにフォローアップをする

実行時に演算プログラムを変更するための方法に関する議論

実行時に演算プログラムを変更できるようにすると, 実行速度 は低下することになるだろう. しかし実行時に演算プログラム を選択できる利点は大きいので, これまで考えてきた USE 文 を用いたプログラムの選択方法に抵触しない範囲でその方法を 検討してみる.

  • ソースコードを変更することなく, 実行時に演算プログラムを変更するためには基本的に NAMELIST を使う
  • 具体的な方法として, 以下の 2 つ案が挙がった.
    • 案 1
      • 切り替えを行う演算モジュールの1つ上位のモジュール で切り替えを行う.上位のモジュールの初期設定手続き において読み込まれる NAMELIST 変数群に演算プログ ラム切り替え用のフラグとなる文字型変数を含んでお き,その変数に与えられた文字列から, 演算するプログ ラムの切り替えを行う.実際には, そのモジュールの演 算プログラム内に, IF 文が出現することとなる.
    • 案 2
      • 切り替えられるそれぞれの演算モジュール自身で実際に 動作するかどうかのスイッチを持つ. 初期設定手続きに おいて読み込まれる NAMELIST 変数群にそのスイッチの 役割を果たす論理型変数を含んでおき, それが真の場合 のみ,演算プログラムの中身が有効となるようにする. つまり, 演算プログラムにおいて,このフラグが偽の際 には, 何もせずに返り値を返してプログラムを終了する.
  • 案 1, 案 2 の場合ともにプログラムのどこかに IF 文を使 うことになる. したがってどちらにしろ計算速度が遅くなる ことは間違いない.
    • dcpam では時間積分法の選択を案 1 の方法で行っている. しかし計算速度の比較は行っていない.
  • 案 2 はサブルーチンを呼び出すプログラム中に条件分岐が 陽に現れないため, 可読性が低下する恐れがある.
  • 案 2 は NAMELIST 型で指定する論理型変数の値を間違える と, 同時に呼びたくないサブルーチンを呼んでしまうことが 起こってしまう.
  • 結論
    • 案 1 の方法で演算プログラムの変更を行うようにする.
    • 案 1 の方法をどれだけ多用するのかはその都度考えて開 発を行うようにする.

AGCM5

  • ISPACK の SMPACK 対応版のコードに対する修正パッチを AGCM5 領域の agcm5-dvlop ディレクトリに格納(石渡)
  • TODO
    • AGCM5 のページに修正パッチへのリンクを作成する.(石渡)

モデルの定式化・離散化マニュアルの作成方法について

  • 方針
    • 離散化マニュアルを見れば, 使用している方程式, 離散化された式, 計算手順がわかるようにする.
      • 離散化マニュアルは, 使用している方程式が与えられたものと して, 記述をはじめる. 式の導出は必要があれば appendix に まとめる.
      • 現在の定式化マニュアルに該当する部分は, 将来的には理論マニュアル のように複数のモデルから参照することが可能な文書として整理する.
  • 今後の手順
    • dcpam4 のドキュメントは上記の構造で作り直しているので, その作業を 引続き行う
    • deepconv は流れマルチメディアの完成後, 改訂を開始. 現在定式化マニュ アル本文に記載されている基礎方程式のリストを離散化マニュアルにカット & ペーストする.

天文台モデルミーティング

  • 日程:
    • 8/17(日) 中に天文台周辺に移動, 8/18(月) 朝から 8/20(水) 夕方 まで (17:00)
  • 現在宿泊施設について調整中

配列添字の付け方について

  • 領域の始点を 0, 終点を max
  • 具体例

    0     1     2     3      max-1      max
    |--1--|--2--|--3--|--....--|--[max]--|
  • 配列を (0:max) までとるか, (0:max-1) までとるかは実装の問題
    • 周期境界の場合, 原理的には (0:max-1) またでよい

プログラムの宣言文部分のコメントの書き方について

  • deepcovn の main プログラムを例に議論を行った
    • use 文のコメント
      • 現状の書き方はうっとうしく感じることがある. なかなか計算開始行に たどりつけない.
      • 個々のモジュールの説明, および引用している変数と手続きに対するコメントを 逐一書く必要はないが, おなじカテゴリのモジュールたちに対するおおまかな コメントは必要だろう
        • 例) gt4f90io 関連, 乱流パラメタリゼーション, 雲物理, など
        • 何も書かないのはよくない, 全くわからなくなってしまう.
      • 実際の書き方については議論の余地がある
        • "---" "===" (ハイフン, およびそれに類するもの) の使い方
        • 次下げ
        • 日英両方書くかどうか, 書く順番
    • 変数宣言部分のコメント.
      • ここはちゃんと書くことにする.
    • 実際の書き方には好みがあるので, 万人が納得するコメントの書き方を定める のは難しいかもしれない.
      • 無理に and はとらない.
      • たとえばプログラムをはじめて 3 ヵ月くらいたった 4 年生/M1 にとって 読みやすいコードにするとか.
  • dcpam, spmodel とも書き方を揃えるべし
    • 森川さん, 竹広さんがいるときに会話する.