John,
I decided to try compiling NJ from source again. For some
reason, it was less trouble than I remember from the past.
Regarding handling of the polar stereographic in WRF
datasets, I found that the southern hemisphere problem
could indeed be easily fixed by correcting line 185 of
WRFConvention.java. In other words, the line which reads
double scaleFactor = (1+Math.sin(Math.toRadians(lat1)))/2.;
should instead be
double scaleFactor = (1+Math.abs(Math.sin(Math.toRadians(lat1))))/2.;
I haven't tried any changes regarding the NMM E grid yet.
rbs
On Sep 4, 2007, at 19:54, Robert B. Schmunk wrote:
On Sep 4, 2007, at 19:23, John Caron wrote:
Hi Robert:
I have no doubt that you are finding real bugs; the WRF projections
are quite difficult to understand; in earlier versions the parameters
are actually wrong(!). If you can email sample files and whatever
fixes you think are right, i will test and see if i can corroborate.
I will be gone till next week, so i will look at it then.
John, I have placed the three sample WRF netCDF files from
NOAA in an anonymous ftp directory at
ftp://ftp.giss.nasa.gov/outgoing/caron
The file names are alaska.nc, tasmania.nc, and geo_nmm.d01.nc.
They add up to about 11 MB.
The alaska and tasmania files are both polar stereographic
files. alaska is the north polar and seems to be read correctly
by the combination of NJ's WRFConvention.java and Stereographic.java
classes, while tasmanian is the south polar and shows the problem
which I described. As indicated, I suspect this is a problem with
the scaleFactor variable calculated in WRFConvention.java. However,
my own experience with trying to compile the NJ libraries from
source was messy enough that in this case I haven't tried to make
the change myself.
geo_nmm.d01.nc is the NMM E file.
The NMM E grid is a completely different beast than the ARP grid. I
need to detect and probably just branch to some new code. I spent a
while figuring it out but didnt finish, i think because since it was
rotated, it violated some assumptions in the GeoGrid code. I think
theres some 2D arrays we could use instead that might be a
workaround, but i forget the details. I can look at that again next
week also.
By "rotated" do you mean that the alternative grid is some form of
a rotated pole?
I haven't seen (well, haven't looked too hard for) NMM E grid
documentation, so don't know what it entails. If it is indeed
some form of rotated pole grid, it seems like it shouldn't be
too difficult to attack since, as you know, I have already
written my own rotated pole transformation code. The main thing
is just figuring out where the pole is rotated to.
rbs
Robert B. Schmunk wrote:
John,
A couple questions/problems regarding using the NJ libraries to
read some sample WRF datasets which have been provided me by
a group at NOAA.
First, I have enabled my Panoply application to recognize WRF
(polar) stereographic data and use the NJ libraries to project it
onto a standard grid. This seems to work just great for northern
hemisphere data, but it turns out that southern hemisphere data
(e.g., Tasmania) is distorted. I have looked at the code for the
Stereographic class, and that seems okay, but I am wondering if
the calculation of "scaleFactor" in line 185 of the WRFConvention
is correct. I note that it doesn't seem to adjust for the change
of sign when lat1 is less than 0 (i.e., in the S.H.), and so
for example, if lat1 = -90deg, scaleFactor would be 0.
If you need it, I can e-mail you the sample S.H. stereographic
dataset. It's about 2 MB.
The second issue regards another WRF grid which apparently is
not yet handled by the NJ libraries, the WRF NMM "E" grid, also
identified as MAP_PROJ=203. The comments in the the WRFConvention
class seem to suggest that dealing with this grid is a hairball,
i.e., I see the scary phrase "special processing". Does this
mean that the likelihood of the NJ libraries being able to
re-project this grid in the foreseeable future is dim?
Also regarding the NMM "E" grid, the sample NOAA dataset I have
is causing WRFConvention to puke a NullPointerException at line
144. Checking the file metadata, I find it contains neither the
GLAT variable which s supposed to be created at line 143 of
WRFConvention, nor the GLON variable to be created further down
at line 149. Is this something that WRFConvention needs to trap
for?
rbs
--
Robert B. Schmunk, address@hidden
NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY
10025
--
Robert B. Schmunk, address@hidden
NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025
