国立天文台共同研究「天体流体運動の理解のための数値モデルの開発と基礎実験」ミーティングメモ

日時: 2008/08/18-20
場所:
- 国立天文台三鷹キャンパス総合情報棟 2F 会議室
- 北大理8号館コスモスタジオ
参加者:
- 天文台: 林祥介, 石渡正樹, 中島健介, 小高正嗣, 高橋芳幸, 杉山耕一朗, 佐々木洋平, 森川靖大, 納多哲史, 高木征弘, 松田佳久
- 北大: 山下達也

8/18

gt4f90io について

最新版 dcpam5 における I/O 関連の

!!!!

use gt4_historyauto, only: HistoryAutoPut, HistoryAutoProgress
...

! リスタートデータ出力
! Restart data output
!
call RestartFileOpen

! リスタートファイルへ初期値データ出力
! Output initial data to a restart file
!
call RestartFileOutput( &
  & xyz_UB, xyz_VB, xyz_TempB, xyz_QVapB, xy_PsB, &   ! (in)
  & xyz_UN, xyz_VN, xyz_TempN, xyz_QVapN, xy_PsN  )   ! (in)

! ヒストリデータファイルの初期化
! Initialization of history data files
!
call HistoryFileOpen

! ヒストリデータ出力のためのへの変数登録
! Register of variables for history data output
!
call HistoryAutoAddVariable( 'U' , &
  & (/ 'lon ', 'lat ', 'sig ', 'time' /), &
  & 'eastward wind', 'm s-1' )
...

do (時間積分)

  ...
  ! ヒストリデータ出力
  ! History data output
  !
  if ( .not. firstloop ) then
    call HistoryAutoPut( 'U',    xyz_UN )
    call HistoryAutoPut( 'V',    xyz_VN )
    call HistoryAutoPut( 'Temp', xyz_TempN )
    call HistoryAutoPut( 'QVap', xyz_QVapN )
    call HistoryAutoPut( 'Ps',   xy_PsN )
  end if

  ! 時刻の進行
  ! Progress time
  !
  call TimesetProgress        ! モデルの管理する時刻を 1 ステップ進める 
  call HistoryAutoProgress    ! I/O ライブラリが持つ時刻を 1 ステップ進める 

  ! リスタートデータ出力
  ! Restart data output
  !
  if ( .not. firstloop ) then
    call RestartFileOutput( &
      & xyz_UB, xyz_VB, xyz_TempB, xyz_QVapB, xy_PsB, &   ! (in)
      & xyz_UN, xyz_VN, xyz_TempN, xyz_QVapN, xy_PsN  )   ! (in)
  end if

end do 
..

議論の内容

I/O ライブラリが時刻を管理しているのが気持悪い.
- I/O ライブラリも時刻を管理している (時計を持っている)
  - HistoryAutoProgress
  - 時計が 2 つある
- ヒストリーデータを出力するタイミングを I/O ライブラリ側で判断している
  - HistoryAutoPut
- I/O はメインプログラムから明示的に call されたときにデータを入出力するべきでは?
  - 時計はメインプログラム(モデル側)だけが持っているべき
- 対策
  - 現在の dcpam5 / gt4f90io (gtool5) の方法を採用する
    - 似て非なる複雑な I/O モジュールをモデル毎に持っているのはいやだ, どうぜ black box なのでほとんどの人は見ないだろう.
    - 積算値の計算を gt4f90io でやってくれるなら時計が 2 つあってもよい
    - 2 つの時計がずれるのではないか, という危惧がある
  - gt4_historyauto モジュール関連は, 全部モデル側の I/O モジュールとして持つ
    - 時計は 1 つ
    - 少なくない行数の black box コードがモデルに含まれることになる
  - 折衷案
    - gt4_historyauto モジュールに含まれる手続きを呼ぶときに, 明示的に時間を渡すようにする.
    - 具体的には HistoryAutoProgress サブルーチンの引数として時刻を渡すようにする. サブルーチン名を HistoryAutoSetTime に変更する.
    - 時計は 1 つになる.
- 方針
  - 折衷案を採用
モデル内の時間管理について
- 2 種類の時計が必要(?)
  - モデルの計算時間を表す時計と暦を表す時計
    - 前者は計算開始時刻を起点とした時計
    - 後者は, YYYY/MM/DD/HH/MM/SS の日射を計算する, という場合に必要な時計
- 原理的には, モデルの計算時間を表す時計と, 計算開始時刻における暦, を持っていればよい
  - 任意の時間ステップにおける暦は, 上記の 2 つを用いて計算できるはず.
  - そのような問い合わせ手続きを用意しておけばよい
  - gt4f90io の dc_date モジュールを使うことで, 比較的楽に実装できる?
- モデル計算時間を表す「秒」と, 地球, 火星, などの惑星に対応した暦との間の換算が必要に応じてできるようになっていればよい (林案).
  - くりあがり単位を用意しておかないと, 長時間計算した場合に丸め誤差が生じることがある
    - 何桁とっておけばよいかは検討の余地あり
  - 火星の場合 1 日の長さを秒で正確に定義すると, その長さを 24 等分することができなかったりすつ.
    - どこかの単位をきりつめて定義せざるをえない
- その他考えておくべきこと
  - 自転角速度と 1 日の長さはリンクさせておくか, させないか
I/O ライブラリの機能に対するリクエスト
- 最初のヒストリーデータを出力する時刻をオプションで指定できるようにしてほしい
  - 100 日計算をはじめに 55 日計算して, そのリスタートデータを用いてさらに 45 日計算する場合を考える. ヒストリーデータは 10 日おきに出力する場合には, 45 日計算のヒストリーデータは 50 日目から 10 日おきに出力して欲しい.
  - 100 日計算で 50 日目から出力したい, ということもあるだろう.
  - この機能はすでに実装済. ただし, 最初のヒストリーデータを出力する時刻を指定すると, 計算開始時刻でのデータを出力できない.
- 可変時間刻みを許容するような設計であってほしい
  - 例えば各時刻の流速と格子点間隔から時間刻みを決めて計算する場合
  - 出力タイミングの決定をステップ数を参照して行うのではなく, モデル内の時間を参照して行うようにすればよいだろう.
- dc_date モジュールにおいて無次元時間に対応する単位 [1] をサポートする
  - 無次元時間
- dc_date において, 1 以下の数字の足し算で丸め誤差が生じないように, および, 100 億年のような時間を表現できるようにする.
  - dc_date 内で, mili_sec (1.0e-3) や micro_sec (1.0e-6), もしくは kilo_sec (1.0e+3), mega_sec (1.0e+6) などの整数型変数を用意し, 実体はこれらに管理させる.
gt4f90io の中に, I/O 以外のサブルーチンが含まれている
- 具体的には「Fortran 90/95 汎用モジュール」に含まれるもの
- どう切り分けるべきか, どこまでが I/O か?
- そもそも gtool4 から I/O 部分だけを切り出したものが gt4f90io だったのでは?
- 対策
  - 現状のまま, 何も変えない
  - ライブラリ名をリネーム, (gt4XXXX ?)
  - I/O と汎用ライブラリを分ける
  - 考慮すべきこと
    - 名前を変えるメリット, デメリットをよく考えた方がよい.
    - まずは身内の人々が「使っても良いかな」と思えないといけない. 我慢できないレベルではだめ.
    - 汎用ライブラリを束ねたモジュールを用意しておけばよい?
      - お気楽ユーザは全部を束ねたモジュールを用意しておけばよいだけでは?
- 方針
  - ライブラリ名を変える
    - gtool4 から gt4f90io へ名前を変更したときの思慮が足りなかった.
    - ライブラリ名は gtool5
      - 階層的数値モデル群のための汎用ライブラリ
      - ライブラリ名: libgt4f90io.a -> libgtool5.a
      - netcdf 入出力: gt4_history -> gtool_history
        
        後方互換のため gtool_history モジュールを use するだけの gt4_history モジュールを用意する
      - 汎用モジュール: dc_XXXX -> dc_XXXX (変更なし)
- プロジェクトディレクトリの整理
  - gtool ディレクトリの下にまとめる
    - 製品はそのしたにサブディレクトリを作成する
  - 移行の手引
    - gtool ディレクトリ (GTOOL3 資源置き場) をまず gtool4 ディレクトリ以下に gtool3 とリネームして移動する.
    - gtool4 ディレクトリを gtool へリネームする.
    - 新しい gtool ディレクトリのトップページから gtool4 の "4" を取り去り, GTOOL3 の資源へのリンクを修正する.
    - gtool ディレクトリのシンボリックリンク gtool4 を作成し, これまでの http:://www.gfd-dennou.org/library/gtool4 で新たな gtool プロジェクトのページへ飛べるようにする.
    - gtool ディレクトリ以下に, gtool5 製品置き場として gtool5 ディレクトリを作成する.
    - gt4f90io は「過去の資源」にする.
    - CVS コミットメールの宛先を gtool4 から gtool に変更.
    - gtool グループユーザの保証人, メンバーを gtool4 のそれぞれに変更
    - gtool4 グループユーザのメンバーは管理上必要な最低限メンバーにする.

8/19

時刻管理と出力制御について

現在 dcpam と deepconv のの出力制御
- dcpam
  
  t=t1 のデータを出力する場合には, t=t1+Δtまで計算する
  - ヒストリデータの時間レベルは t=t1
    - 時間フィルタのかかったデータが出力される
  - リスタートデータの時間レベルは t=t1-Δt, t=t1
    - ここでの t=t1 のデータには時間フィルタはかかっていない
  - 積算値を計算するときには t=t0+Δt から t=t1 までのデータを使う
```
t=t0           t=t1
 |--|--|--|--|--|--|
                  t=t1+Δt
```
- deepconv t=t1 のデータを出力する場合には, t=t1 まで計算する
  - ヒストリデータの時間レベルは t=t1
    - 時間フィルタのかかってないデータが出力される
  - リスタートデータの時間レベルは t=t1-Δt, t=t1
  - 積算値を計算するときには t=t0 から t=t1-Δt までのデータを使う
```
t=t0           t=t1
 |--|--|--|--|--|
```
- それぞれの方式の問題点
  - dcpam 方式では飽和調節後の値に時間フィルタをかけてしまうので, 100% 飽和が保証されない
  - deepconv では時間フィルタかけられていない力学過程の予報変数が出力されている
予報変数の出力方針
- t=t1 のデータを出力する場合には, t=t1+Δt まで計算し, t=t1 の時間フィルターのかかっていないデータを出力する.
- 計算開始時刻のデータは原則出力する
  - オプションで出力しないようにしてもよい. 石渡さんのリクエストにより, dcpam5 ではこの機能を実装する.
Tendency と積算値について
- Tendency と積算値とは違うことに注意
  - 積算値は増分 (ΔA) の和なので, 積算開始時刻と終了時刻の 2 つ時刻ラベルを持つ
  - Tendency の時刻ラベルは 1 つ
- Tendency の出力時刻は出力データ数は, 予報変数と一致させる.
  - そのために時間積分ループは 1 ステップ多く回す.
時刻管理と出力制御についての議論
- HistoryAuto モジュール側でデータの出力するタイミングを制御してくれるのであれば, 時間積分ループの構造は単純にできる
  - 一方で HistoryAuto が勝手に判断して動作するのは気持悪いという意見もある.
    - オートマの車は嫌だ, という感覚に似ている
    - My カスタムカーではない, という感覚とも似ている
  - HistoryAutoPut が call される度に出力時刻がどうか判断する条件分岐によって, 実行速度を低下させることにならないか? 実際に試してみないとわからない.
    - 大して影響しないのではないか, という希望はある.
- 時間積分ループの制御をステップ数で行うのはよくない. 時間刻みが可変になった場合を考慮すると, 時刻で制御するべきだ.
  - ループ回数を明示的に与えるのではなく, 時刻がこの値を越えたらループを抜ける, という制御にする
  - 時刻変数は実数なので, 長時間積分を行うと丸め誤差が生じる恐れがある. これを防ぐためには dc_date モジュールにしかるべく対策が必要.

時間積分ループ構造の検討

素直にループを記述した場合. HistoryAuto は現在の仕様.

do i = 1, N

  Time = Time0 + dt*i

  Tendency = f(VarN, VarB)
  call HistoryAutoPut(Tendency)  ! t=Time-Dt の Tendency を出力

  call HistoryAutoSetTime(Time)  ! 出力用の時刻設定

  VarA = VarB + 2.0*Dt*Tendency
  call HistoryAutoPut(VarA)      ! t=Time の Var を出力

  call timefilter(VarA, VarN, VarB) ! 時間フィルタ

  VarB = VarN
  VarN = VarA

end do

最後に Tendency を 1 ステップ余分に計算する場合. HistoryAuto は現在の仕様.

do i = 1, N+1

  Tendency = f(VarN, VarB)
  call HistoryAutoPut(Tendency)  ! t=Time-Dt の Tendency を出力

  FooTendency = f(FooN, FooB)
  call HistoryAutoPut(FooTendency)  ! t=Time-Dt の Tendency を出力

  TimeA = TimeN + dt
  call HistoryAutoSetTime(TimeA)  ! 出力用の時刻設定

  exit if (i=N+1)                ! 最後のループは Tendency だけ計算して
                                 ! ループを抜ける

  FooA = FooB + 2.0*Dt*FooTendency
  VarA = VarB + 2.0*Dt*VarTendency

  call Adjustment(VarA)          ! VarA の調節

  call HistoryAutoPut(VarA)      ! t=Time の Var を出力
  call timefilter(VarA, VarN, VarB) ! 時間フィルタ

  VarB = VarN
  VarN = VarA

  TimeB = TimeN
  TimeN = TimeA 

end do

HistoryAutoPut の引数に出力時刻を与える場合

do i = 1, N+1

  TimeA = TimeN + dt

  Tendency = f(VarN, VarB)
  call HistoryAutoPut(TimeN, Tendency)        ! t=TimeN の Tendency を出力

  FooTendency = f(FooN, FooB)
  call HistoryAutoPut(TimeN, FooTendency)     ! t=TimeN の Tendency を出力

  tmp_VarA = VarB + 2.0*Dt*VarTendency

  call Adjustment(tmp_VarA, adjust_tendency)  ! Var の調節
  call HistoryAutoPut(TimeN, adjust_tendency) ! t=TimeN の Tendency を出力


  exit if (i=N+1)                ! 最後のループは Tendency だけ計算して
                                 ! ループを抜ける

  VarA = VarB + 2.0*Dt*(VarTendency+adjust_tendency)
  FooA = FooB + 2.0*Dt*FooTendency

  call HistoryAutoPut(TimeA, VarA)  ! t=Time の Var を出力

  call timefilter(VarA, VarN, VarB) ! 時間フィルタ

  VarB = VarN
  VarN = VarA

  TimeB = TimeN
  TimeN = TimeA 

end do

HistoryAutoPut の引数に出力時刻を与え, HistoryAutoPut が各変数を出力するタイミングを判断してくれる場合 (決定案)

call HistoryAutoCreate   ! Var, Foo, Tendency の出力時刻,
                        ! 出力終了時刻(EndTime)を与える

do while (TimeA <= LoopEndTime)  ! ループの制御は時刻変数で行う

  TimeA = TimeN + dt

  Tendency = f(VarN, VarB)
  call HistoryAutoPut(TimeN, Tendency)        ! t=TimeN の Tendency を出力

  FooTendency = f(FooN, FooB)
  call HistoryAutoPut(TimeN, FooTendency)     ! t=TimeN の Tendency を出力

  tmp_VarA = VarB + 2.0*Dt*VarTendency

  call Adjustment(tmp_VarA, adjust_tendency)  ! Var の調節
  call HistoryAutoPut(TimeN, adjust_tendency) ! t=TimeN の Tendency を出力


  VarA = VarB + 2.0*Dt*(VarTendency+adjust_tendency)
  FooA = FooB + 2.0*Dt*FooTendency

  call HistoryAutoPut(TimeA, VarA)  ! t=Time の Var を出力
  call timefilter(VarA, VarN, VarB) ! 時間フィルタ

  VarB = VarN
  VarN = VarA

  FooB = FooN
  FooN = FooA

  TimeB = TimeN
  TimeN = TimeA 

end do

小高さんが気持よいループ構造. deepconv/arare4 はこれに近い構造をしている. でもこのように書けないことが多々あるだろう.

do i = 1, N+1

  TimeA = TimeN + dt

  Tendency = f(VarN, VarB)
  call HistoryAutoPut(TimeN, Tendency)  ! t=TimeN の Tendency を出力

  tmp_VarA = VarB + 2.0*Dt*VarTendency

  call Adjustment(tmp_VarA, adjust_tendency)       ! Var の調節
  call HistoryAutoPut(TimeN, adjust_tendency)  ! t=TimeN の Tendency を出力

  VarA = VarB + 2.0*Dt*(VarTendency+adjust_tendency)


  FooTendency = f(FooN, FooB)
  call HistoryAutoPut(TimeN, FooTendency)  ! t=TimeN の Tendency を出力

  FooA = FooB + 2.0*Dt*FooTendency

  call HistoryAutoPut(TimeA, VarA)  ! t=Time の Var を出力
  call timefilter(VarA, VarN, VarB) ! 時間フィルタ


  VarB = VarN
  VarN = VarA

  TimeB = TimeN
  TimeN = TimeA 

end do

gt4_historyauto モジュールの仕様に対する要望リスト
- HistoryAutoPut: 引数にモデルの現在時刻を与えられるようにする
  - 与えた現在時刻があらかじめ設定した出力時刻に等しい場合には出力
  - 出力終了時刻を越えていたら出力しない
- 与える時刻変数の型は dc_date_types モジュールで提供される DC_DIFFTIME 構造体とする.
モデルの現在時刻の与え方はどうすればよいか
- dc_date モジュールで定義される DC_DIFFTIME 構造体で与える
  - 丸め誤差が生じないように, 適当な繰り上がり単位を持つ
  - 必要に応じて特定の暦や有次元時間に換算できるようにしておく
    - 実装をどうするかは検討が必要(たとえば火星の暦を使う場合)
  - 現在時刻を与える変数は, メインプログラムで管理しサブルーチンの引数として渡すべきか, モジュールて定義し必要なサブルーチン内で use して共有すべきかは悩む問題だ.

8/20

種別型パラメタの設定について

gt4f90io ライブラリの dc_types モジュールで提供される種別型パラメタ "DP" の扱いについて
- dc_type では, "DP = kind(0.0d0)" と定義されている
- "DP" を使うメリット
  - 数値モデルと gt4f90io で使用する実数の精度が時動的に一致する
    - 精度拡張オプションのあるコンパイラであれば, コードを書き換えなくても 4 倍精度指定可能
    - モデルと gt4f90io で実数の精度指定が異なると, モデルのコンパイル時にエラーが生じてしまう.
      - モデルでは 4 倍精度で計算し, そのデータを出力する場合はあらかじめ gt4f90io の実数型を 4 倍精度指定でコンパイルしておかなくてはいけない
        
        モデルで指定されている精度に対応して, gt4f90io がよろしく判断してくれるならよいが, 現状ではそのようにはできない.
  - real(kind(1.0d0)) のように書くのは面倒
- デメリット
  - 精度指定を陽に変更したい場合には, gt4f90io から再コンパイルしないといけない
  - gt4f90io に必要以上に依存するのはよくないのではないか?
- モデルで持っているべきか, ライブラリで持っているべきか.
- 数値モデルでの使用状況
  - dcpam5, deepconv/arare4 (3D 版) では使っている
  - deepconv/arare4(2D版), spmodel では使っていない
- 方針
  - dc_types モジュールの "DP" を使う
  - deepconv では 3D 版の精度指定方法に揃える

単精度実数の精度指定

gt4f90io では単精度実数の精度指定のための種別型パラメタはない
数値モデル中では "real :: hogehoge" と定義している.

"DP" と同様に "SP = kind(0.0e0)" を用意しておくべき?

具体例

! 現在の dcpam, deepconv の書き方
! A は本当は DP ではないか, という疑念が湧く人もいる
real     :: A        
real(DP) :: B    

! 単精度実数も明示的に精度指定する場合
! 
real(SP) :: A 
real(DP) :: B

! 種別型パラメタを小文字で書く場合
! 
real(sp) :: A 
real(dp) :: B

! F77 以来の書き方
B = 1.0d0               

! F90 で可能になった書き方
! gt4f90io, dcpam ではこのように書いている
B = 1.0_DP

対策
- 今は SP は用意しない
- でも将来的には SP を用意した方が混乱を生じないだろう

大文字小文字問題
- dcpam, gt4f90io では大文字で定義される言語要素がある. これは C 言語においてプリプロセッサが解釈される文字列を大文字で表記する慣習と衝突する.
- 対策
  - プリプロセッサを本格的に使用するときにあらためて考える
Tendency を格納する変数名
- dcpam5 : DUDt <- こっちだとおもうけど
- spmodel: DtDU, DtDLplalaPorVel
dcpam5 ソースコードの検討
- 初期化
- リスタートデータ入力 (RestartFileGet)
  - NAMELIST でリスタートファイル名が与えられた場合は, そのファイルからデータを読み込む
  - NAMELIST でリスタートファイル名が与えられていない場合は, デフォルトの初期値を生成して返す
    
    ! リスタートデータ入力 ! Restart data input ! call RestartFileGet( &
```
& xyz_UB, xyz_VB, xyz_TempB, xyz_QVapB, xy_PsB, &   ! (out)
& xyz_UN, xyz_VN, xyz_TempN, xyz_QVapN, xy_PsN  )   ! (out)   
```
- 新しい計算を開始する場合に 1 ステップ目はオイラー法で計算している
  - deepconv も同様
  - 精度を保証するなら 1 ステップ目は 2 次のルンゲクッタなどで計算する
  - 1 ステップ目の計算方法は今後の検討事項
    - 時間刻みを可変にすれば解決できる?
- リスタートデータ出力 (RestartFileOutput)
  - t=0 のデータをリスタートファイルに出力するのはやめる
- 出力変数の登録 (HistoryAutoAddVariable)
  - ソースコードでは出力する可能性のある変数をすべて登録
  - 実際に出力するかどうかは, NAMELIST で制御する
    - デフォルトでは予報変数のみ出力, 必要に応じて診断変数を出力できるようになっている
- HistoryAutoPut の引数の並べ方
  - 案 2 つ
    - HistoryAutoPut( 'U', xyz_UN, TimeN )
      - gtool 変数の指定方法と整合的
      - HistoryPut の自然な拡張に見える
    - HistoryAutoPut( TimeN, 'U', xyz_UN )
      - 時間軸に沿ってデータを格納する, というイメージと整合的
  - 方針
    - HistoryAutoPut( TimeN, 'U', xyz_UN ) とする
- HistoryFileOpen サブルーチン
  - 初期化終了フラグ変数 "history_file_io_inited" は, フラグ変数であることがわかる接頭詞をつけた方がよい
    - ex. flag_history_file_io_inited とか
    - 懸案としては, モジュール名が長い場合, フラグ変数の文字数が 31 を越えてしまわないか
deepconv への改善リクエスト
- リスタートデータは計算終了時に一回だけ出力するのではなく, 適当な時間間隔で複数出力できるようにしておいた方がよい

今後のタイムスケジュール

それぞれのプロジェクトの ToDo サマリ
- gtool5
  - dc_date の改良
  - gt4f90io を gtool5 としてリリース
  - gtool プロジェクト web ページの整理
  - gt4_historyauto の改良
- dcpam5
  - ヒストリーデータを出力する時間ステップの変更
  - 時間積分ループをステップ数ではなく時刻で制御する
  - 実際に使ってみて問題点の洗い出しを行う
    - 納多さんにユーザになってもらう
  - 並列化
    - gtool のように数値モデルの並列化のための共通基盤が作れるとよいのだが
  - 実行速度を AGCM5 と比較する
  - 複数のトレーサを計算できるようにして欲しい
    - 現在は水蒸気決めうち
    - 例えば火星のダストを計算したときに困る
    - deepconv の方法が参考になる?
  - モデルのアルゴリズムを解説する文書が欲しい
    - 陰解法の計算方法など, 論文などの参照文献が存在しない部分の解説
  - AGCM5 に導入されている物理過程の移植
  - 火星条件で計算可能にする
    - 具体的に導入するプロセスについては後日検討
- deepconv
  - 並列化
  - 3D 版に凝結過程の組み込み
  - ドキュメントの整理
    - 流れマルチメディアのモデル解説をもとに書き換え
    - 構成を dcpam5 のドキュメントに揃える
  - ヒストリーデータを出力する時間ステップの変更
  - gt4_historyauto の導入
  - 時間積分ループをステップ数ではなく時刻で制御する
  - 2D 版と 3D 版コードの書き方の整理
- その他
  - 階層モデル化
    - 軸対称モデル
    - 平面 2D モデル
    - 1D カラムモデル
    - EBM
スケジュール
- 〜09/20
  - gtool5 のリリース
    - dc_date の改良
    - gt4_historyauto の改良 (gtool_historyauto とする)
    - gtool プロジェクト web ページの整理
- 〜10/22
  - dcpam5
    - gtool_historyauto 導入
    - ヒストリーデータを出力する時間ステップの変更
    - 時間積分ループをステップ数ではなく時刻で制御する
    - dcpam5 の実行速度を AGCM5 と比較する
    - 複数のトレーサを計算できるようする
    - モデルのアルゴリズムを解説する文書を作成する
    - AGCM5 に導入されている物理過程の移植
  - deepconv
    - ドキュメントの整理
    - gtool_historyauto 導入
    - ヒストリーデータを出力する時間ステップの変更
    - 時間積分ループをステップ数ではなく時刻で制御する
    - 2D 版並列化