動作環境

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次元コードを実装したときは、格子の中心座標を扱っていたと思う。