玉川研究室で、CReSS を使うには。5
実際に計算を行ってみる。

今までのページでは、以下のことを説明した。

ここでは、これらを使って実際に計算を行ってみる。

まず、概略をのべると以下のような形になる。

この結果、ある時刻の計算結果が１ファイルという形で、計算結果が出力され、 それを解析する。
更に、one way nesting をするのならば、出て来た計算結果を上の気象データの処理と同様に処理し、
次の更に細かい格子での計算の際の初期条件、境界条件に用いて計算を行う。

各実行ソフトの作成

「はじめに」で説明したように、まず作業ディレクトリ (ここでは、Takayama2006) を作成し、
そこに、CReSS を展開し、必要な変更を行う。
mkdir Takayama2006
cd Takayama2006
tar zxvf    ~tama/CRESS/Tars/cress2.1m.tar.Z
cd CReSS2.1m
vi  User_Mod/declmpi.f90     ( declmpi.f90 の編集ができれば良い。vi で
                               なければならない必要は全然ない。vi を起動して
			       出方がわからなくなったら、エスケープキー : q! で
			       終了できる。)
	16行目の use mpi を 行頭の ! でコメントアウトして、
	18行目の !     include 'mpi.h' の行の ! を空白で置き換えて活かす


compile.conf の中で以下を設定


    LDFLAGS = -O3
    FFLAGS  = -O3
    FC      = ifort   ( ubuntu1 などでは gfortran [2011追加])
ここで、必要なソフトをコンパイルする。
./compile.csh gridata
./compile.csh terrain
./compile.csh surface
./compile.csh unite
solver だけは、もしかしたら -O3 じゃなく -fast でコンパイルした方が
速くて良いかもしれません。他のは、どうせ大した実行時間がかかる訳ではないので
-O3 でコンパイルして、tamacalc1 でも動くようにしておくのが便利でしょう。
(2006.8.30 追記)
なんとなく、-fast でコンパイルすると、途中で計算がおかしくなる
(パイプ破壊が起きる)ような気がします。充分調べた訳ではないので、不確かですが。(2006.9.4)
./compile.csh solver
再度、コンパイルする必要があれば、 
./compile clean
を行った後、上を繰り返す。
註: ここで -fast という強力な最適化を行うと、
今作業している tamacalc1 (並列計算機のフロントエンドのノード)のCPU Xeon では
もはや動かない実行形式になっている。計算ノードではもちろん動作する。

設定ファイル user.conf の書き方

まずは元にする user.conf.2.1m.recomended をコピーする。 
cp /home/tama/CRESS/Tars/user.conf.2.1m.recommend ./
そして、user.conf の編集に入る。
ここで、Doc/readme.user.conf と、CReSS のマニュアル (特に9章) は必読である。
まず、最初に、sysdep の wlngth であるが、 Intel Fortran を使って 計算する時は、 wlngth = 1 である。
(gfortran の時は wlngth = 4 である: バイト単位 [2011追加] ）
これは、Fortran の規格では、システム依存になっている unformatted direct access
データの読み書きの単位(word)のバイト数と関係している。
コードをみると、open 文でレコードの長さを決める recl に、(nx-3)*(ny-3)*wlngth と いうような
表記が見られる。もし、reclの単位が、バイトなら wlngth は 4 (real 変数が 4バイトだから)
となるべきであるが、Intel Fortran をここで使った場合は recl の単位は word (=4bytes) であったので
recl = 変数の数 となるべき、すなわち wlngth=1 でするべきである。
ただし、最新のバージョンでは無視されるという説明が readme.user.conf に書かれている。(でも、そんなことは無いように見える) 
 &sysdep
 wlngth = 1
 savmem = 1
 /
となる。
次に、実験名(今回は、 takayama2006a とする)を 
 &runame
  exprim = 'takayama2006a'
 /
と設定する。

CPU数、格子数、計算範囲を次に設定する訳だが、今回は、MANAL の 10km の 1/5 と
少し小さめの 2km の水平格子で、100前後の格子数、にすることにする。中心の緯度経度は、
うちの研究室で使っている、杉林タワー ( 21世紀COE「衛星生態学創生拠点」
常緑針葉樹観測サイト = C50サイトの観測タワー) の位置
( 北緯36度08分23秒、東経137度22分15秒、標高800m) を使う事にする。
36度08分23秒 = 36.13972、137度22分15秒 = 137.37083 である (うーん、中途半端な。。) 。
また、CPU数と格子数には依存関係があって、X (Y) 方向の格子数 xdim (ydim) は、
X (Y) 方向の領域分割に使うCPU数 xpedim (ypedim) と、
xdim = n * xpedim + 3 ( ydim = m * ypedim + 3 ) の関係 (m,n は自然数)を
満たさないといけない。
ここでは、全てのCPUを使う事にして、 xpedim = 2 ypedim = 4 とすることにすると
xdim = ydim = 103 が条件を満たす格子数である。
鉛直方向には、対流圏界面を越えるところまで計算領域を取りたい
(対流雲が発達すれば、そこらへんまで上昇するから) 、
一方、地面に近い所は、観測タワーの高度の30m程度の格子は欲しい。
しかし、例えば、鉛直方向に 12km くらい 取ることにすると、12*1000/30 = 400 格子となり、
とても取れる量ではない。また、非常に偏平な格子になることも気になる (これは、なかなか回避できないが)。
そこで、平均200m間隔の格子を 60個用意することにして、その格子間隔を 下の方を小さく、
上で大きくなるように全層でストレッチングする(最下層が30m)ことにする。
(ちょっと無理しているかも知れない。)
こんなことを考えて、以下のように設定する。

 &dimset
  xpedim =   2
  ypedim =   4
  xdim   = 103
  ydim   = 103
  zdim   =  60
 /

 &project
  mpopt =   2
  nspol =   1
  tlat1 =  30.e0
  tlat2 =  60.e0
  tlon  = 137.4e0
 /

 &gridset
  dx   = 2000.e0
  dy   = 2000.e0
  dz   =  200.e0
  ulat =  36.13972e0
  ulon =  137.37083e0
  riu  =  51.e0
  rju  =  51.e0
 /

 &gridsth
  zsfc   =    -0.001e0
  zflat  = 12000.e0
  sthopt =     1
  dzmin  =    30.e0
  layer1 =     0.e0
  layer2 = 12000.e0
 /
ここで、project は計算領域の地図の設定である。
計算領域の中心付近の(51, 51)格子点に、観測タワーの位置がくるようにしている。

長くなって来たので、次へ ここをクリック