動作環境
Xeon E5-2620 v4 (8コア) x 2
32GB RAM
CentOS 6.8 (64bit)
NCAR Command Language Version 6.3.0
for WRF3.7.1, WPS3.7.1
openmpi-1.8.x86_64 とその-devel
mpich.x86_64 3.1-5.el6とその-devel
gcc version 4.4.7 (とgfortran)
for WRF3.9, WPS3.9
Open MPI v2.1.1
gcc version 4.9.2 (とgfortran; devtoolset-3使用)
NetCDF v4.4.1.1, NetCDF (Fortran API) v4.4.4
Python 2.6.6 (r266:84292, Aug 18 2016, 15:13:37)
Python 3.6.0 on virtualenv
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
date (GNU coreutils) 8.4
tmux 1.6-3.el6
WRF(Weather Research and Forecasting Model)とその前処理であるWPS、およびWRFの後続処理のF***T関連。
F***Tの処理において緯度経度の処理情報を整理している。
Case 1
- DX (X方向の緯度増加分): 0.120 度
- DY (Y方向の軽度増加分): 0.120 度
- NUMX (X方向のピクセル数): 82
- NUMY (Y方向のピクセル数): 65
結果として生成されるNetCDFファイルの緯度範囲（経度範囲）は、以下の計算の値と0.06度下側(左側)にずれる。
- 左側経度 + DX + NUMX
- 下側緯度 + DY + NUMY
Case 2
- DX (X方向の緯度増加分): 0.060 度
- DY (Y方向の軽度増加分): 0.060 度
- NUMX (X方向のピクセル数): 82
- NUMY (Y方向のピクセル数): 65
結果として生成されるNetCDFファイルの緯度範囲（経度範囲）は、以下の計算の値と0.03度下側(左側)にずれる。
推測
Case 1, Case 2ともに、DX(DY)の半ピクセル分のずれが発生しているようだ。
格子の計算でピクセルの中心の値を使っているのだろうか。
この症状自体は問題というわけではないだろう。
13年くらい前にFDTD (Finite Difference Time Domain)メソッドの2次元コードを実装したときは、格子の中心座標を扱っていたと思う。