[ 地球流体電脳倶楽部 / dcmodel / メモのファイルリスト / SIGEN.htm ]
- 参加者
- 引用例で挙げられるプロジェクト名がページによって異なっている問題
- dcpam4 の開発状況 (森川)
- dcpam3 に関して (石渡)
- gtool4 netCDF 規約の CF 規約に対する位置づけに関して (石渡)
- gtool4 netCDF 規約の「引用文献」の CF 規約へのリンクの修正 (石渡)
- dcrtm
- deepconv
- dcmodel コーディングルールの修正
- 初期値生成コードの管理について
- NAMELIST ファイルの書式について
- spml の wa_module から rn, irm を参照する問題
- gt4f90io の解説文書の英語化
- モデル開発してて面倒と感じることいろいろ
- 石渡 正樹, 小高 正嗣,
高橋 芳幸, 杉山 耕一朗,
森川 靖大,
山下 達也, 徳永義哉 (順不同, 敬称略)
- dcmodel プロジェクトと gtool4 プロジェクトと同様に
davis プロジェクトのプロジェクト名も変更する予定.
davis プロジェクトの使用上の注意も作成する予定 (石渡)
- dcmodel プロジェクトと gtool4 プロジェクトの中身の整理 (石渡)
「gtool4 とは」はあるけど, 「dcmodel とは」がないなどの
不整合を整理する.
- 一応リリースした.
- DCPAM プロジェクトのトップページを書き換える.
- spmodel のように, モデルの詳細情報などは一段下に
さげ, 「dcpam によっておこなった計算いろいろ」を
もうすこしトップページの上部に入れる.
(現在, 「計算例」はページのかなり下のほうにある).
- モデル本体の改良
- dcpam3 に導入されていた ape 実験用物理過程をどんどん取り込む.
- 初期値生成に関しての構造を 初期値の生成に関して
のようにする.
- 現在セミインプリシットになっているが, エクスプリシットスキーム
にも変更できるよう改造 (8 月末あたりに).
- ドキュメントの移行もこれから
- ソースコードを直接いじらないレベルのユーザ用ドキュメント
『ごくらく DCPAM』の作成
- ソースコードをいじるレベルのユーザ用ドキュメント
『らくらく DCPAM』の作成
- 数理ドキュメント, 離散化ドキュメントは dcpam3 から単純移植予定.
- 数理ドキュメントはコードに合わせた式にした方が良いか??
(DCPAM は U = u cos φ を使ってない, とか).
- AGCM5 の『コード解説』に関してもコード内の変数を入れ替えて
移植する. ディレクトリ名は code_description (仮).
- これまでできたソースコード, プログラム構造,
ドキュメントのチェック (石渡)
計算していて地表面気圧がどんどん増えてしまう問題に関しては
調査を継続中. 目星はついてきた.
gtool4 netCDF 規約再検討北大メンバーミーティング (
1,
2,
3 )
にて議論が中途半端になっている, gtool4 規約の今後について一応の方針を
ちゃんと決める.
なお, 最近 (とはいえ既に昨年秋だが),
CF 規約の White paper
が公開されており,
CF 規約のホームページ
も新しくなっている. これらをチェックすべきかどうかも要検討.
現在, CF 規約の bounds について調査開始 (gt_calc_weight の代替になり得
るか? など)
現状の CF 規約のリンクは
standard name テーブルのリンクは
となっている. CF 規約自体のリンクは, http://www.cfconventions.org/ へ
と転送されるが, standard name テーブルのページは転送されない.
(つまりはリンク切れ)
それぞれ,
と
に変更する. (石渡)
ちなみにこの <URL:www.cfconventions.org> の
実体は <URL:cf-pcmdi.llnl.gov>
報告事項
- 徳永君は放射伝達の勉強を継続中.
- 木星大気の放射伝達計算に向けた作戦を検討した.
Todo:
- dcmodel の英語版ページからのリンクを作成 (日本語版は既にある)
- 大気放射関連の理論マニュアルがあるかどうか確認
覚書
- データが集まった時点で, 何種類の吸収成分気体(バンド)
を考慮すべきか, 検討する
- まずは可能な限り考慮する, でよいが, とある時点でバンドの
取捨選択をしないとたぶん計算できないモデルになってしまうだろう.
- Appleby and Hogan (1984) の再計算は年度内にできてないと後々困る.
(しかし, 放射のインターフェース (deepconv や dcpam などの
メインプログラムとのデータのやり取りの仕方) の検討も必要なので, 大変)
- 並列化はじめました
- 3 次元化はじめました (小高)
- 乾燥対流を計算するコードを CVS root にコミットした.
- 凝結成分の種類をもう少し簡単に変更できるように改良を始めた.
- 目標は地球版よ木星版の実行プログラムをプリプロセッサを使って
単一のメインプログラムから作成すること
- NH4SH の反応に関係するサブルーチンの整理を始めた
「リスタートファイルとヒストリーファイル」の
「ヒストリーファイル」に以下の記述を追記 (石渡)
平均値を計算する際に座標重みを必要とする数値データの場合には, 座標重
みのデータも各ヒストリーファイルに格納することを推奨する.
この際, 実際に netCDF ファイルにどのように座標重みを格納するかについても
記述する. これに伴い, これまでの gtool4 規約において gt_calc_weight として
使用されていた座標重み指定のための属性を CF 規約 bounds に置き換えることが
可能かどうかを調査する. (石渡)
- 長期 RUN 用実行プログラムは「お試し Run」できるように, 内部で
初期値を生成できるようにしておく.
- 本当に数値実験を行う際にわざわざ長期 RUN 用実行プログラムを改変
しなくて済むよう, 初期値生成用実行プログラムは別途用意しておく.
- ただし完全に別々に RUN 用ファイルと, 初期値生成用ファイルを
メンテナンスする場合, 実際に初期値を生成するコードを「2 度書き」
せねばならず, 開発者のストレスが溜まる (deepconv 開発の経験)
- 現状の折衷案 (とりあえずこれで試行錯誤してみる)
初期値生成「モジュール」を用意し, 実際に初期値を生成するコードは
そのモジュールでくるんでおく. 別途, 初期値生成のみのための実行プログラム,
長期 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
｜
└──────────────────
これまで dcpam, deepconv の NAMELIST ファイルでは以下のように
変数グループを記述していた.
&grid_3d_nml
im = 64 ! 東西格子点数
jm = 32 ! 南北格子点数
km = 16 ! 鉛直格子点数
/
これまで, frt, ifort, g95 で動作は確認されていたが, Fortran 95 規格
に正しく沿うと
&grid_3d_nml
im = 64, ! 東西格子点数
jm = 32, ! 南北格子点数
km = 16 ! 鉛直格子点数
/
のように各変数はカンマで区切るのが正しいため, この書式に変更する.
なお, dcpam ではカンマが入っているものと入っていないものとがあったため,
一部の NAMELIST 変数グループが読み込まれないという事態が発生していた.
wa_module.f90 に以下の行を足してコミット.
public :: rn, irm
マイナーバージョンを上げて, リリースする.
その他 2006 年度末に話し合った内容に関しては,
天文台モデルミーティングログ 2006/12/25-27
を参照のこと.
dc_types と dc_message に関しては英語版チュートリアル 作成.
(ソースコードの例のコメントはまだ日本語).
ソースコード例に関しては, メンテナンスの手間を減らすため,
コメントの部分には日本語と英語を併記する. 英語ページには
「Note that Japanese and English are described in parallel.」
と書いておく.
最近作成された dc ユーティリティのチュートリアルに関しては
英語版を作る (小高)
以下の, 日頃作業する際に調べる面倒だなぁ, と思う事柄に関して, dcmodel
のページから 1 ホップぐらいで手繰れるところに, 必要最低限の資料を作成
する. (杉山)
- cvs commit が面倒
- (面倒) コマンドをすっかり忘れているので, わざわざいちいち調べなけ
ればならない (コミットするのが億劫になる). 調べる情報も dcmodel
プロジェクトの奥のほうにあったりして調べる作業も鬱陶しい.
- 調べるものの例
- cvs のタグの貼り方どうだっけ??
- cvs のコミットどうするんだっけ?? なんかルールもあったような??
- (対応策) 杉山氏が, 自分で cvs コミットの際に必要な情報を
dcmodel ページの上の方 (検索しやすい位置) に作ってみる.
- ソースの公開版の更新が面倒
- 作業そのものはだいぶ簡素化されている (タグが書き込まれているファイル
を書き換え, あるディレクトリで make するだけ).
- やり方が流布されれば OK ??
- gt4f90io の開発についていけない
- (面倒) なんかいろいろ開発してるらしいが, ついてゆけん.
- (解決策??) 基本的には History 系 (もうそんなに仕様変更されないことが
期待される) のみは追うけれども, 最近作っている目新しいツールは
無理して追いかけない. (面白そうならその時に聞く).
dcmodel Development Group / GFD Dennou Staff 
Last Updated: 2007/08/29 (森川 靖大), Since: 2007/08/29 (森川 靖大)