Re: data array dimension size

Hi Matt,

I cannot speak for GDAL, but I think that in fact there is no
substantive difference between NCL's
interpretation of this data and wgrib's interpretation. The confusion
stems mostly from the
conventions NCL uses to name grid dimensions that have 2D coordinate
variables. In the case
of your sample file, the data variable A_PCP_GDS5_SFC_acc1h has the
dimensions:

( g5_x_0, g5_y_1 )

However, the dimension g5_x_0 is actually the 'slow' dimension and has
a size equal to what wgrib
(and the GRIB 1 documents) refer to as 'ny' or 'Ny'. Similarly, g5_y_1
is the 'fast' dimension and has size 'nx'.

I am not sure why the decision was made to name the dimensions this
way, and it has always seemed
unnecessarily confusing to me. For that reason, in the implementation
of the GRIB 2 reader I reversed
this usage (probably just adding to the confusion -- but I hope not).

Also somewhat contributing to the confusion is the fact that wgrib
lists the dimensions in the order nx, ny.
This is a Fortran ordering -- i.e. nx is referring to the 'fast'
dimension and 'ny' to the slow dimension.

(At least that is true in this case, given the scanning mode of this
GRIB record -- something that could
complicate this discussion even more, but not a factor here.)

At any rate, NCL and wgrib really have the same idea about the ordering
of the data in this GRIB file. Only the
terminology is different. As confirmation I performed the following
experiment:

Get a text dump of the record using wgrib:

wgrib -d all -o temp -text ST4.2002010100.01h

# get rid of the first line which just has the dimension sizes and
remove temp file

sed -e'1d' wgrib.dump
rm temp

# run this NCL script

f = addfile("ST4.2002010100.01h.grb","r")
v = f->A_PCP_GDS5_SFC_acc1h
; change _FillValue to match wgrib's

v@_FillValue = 9.999e+20

asciiwrite("temp",v)

# process this temp file to remove spaces at the beginning of numbers

  sed -e's/^[ ]*//' temp > ncl.dump

# compare wgrib.dump and ncl.dump

diff wgrib.dump ncl.dump

# no output is produced so the data are exactly the same.

We should probably add a discussion of this confusing issue to our NCL
quirks page.
I am actually surprised that no one has brought it up before.
  -dave

On Jul 12, 2007, at 2:18 PM, Matt Fearon wrote:

> Hi,
>
> I am experimenting with a grib file, trying to perform calculations on
> the data, and then map. See the grib file attached. When reading the
> attached grib file with NCL, the dim order for the imported variable
> is var(x=881,y=1121). When printing the statistics on the grib file
> with wgrib, the dim order is the same, ie, var(x,y), but the dim sizes
> are reversed, var(x=1121,y=881). GDAL is consistent with wgrib. I
> would like to have NCL read these data the same as GDAL, or be able to
> have NCL perform some array reordering to make the data arrangement
> consistent. How can I do this in NCL?
>
> I am familiar with how NCL and fortran differ in array dim order, ie,
> NCL var(y,x) would translate to var(x,y) in fortran. However, in this
> case, my findings retain the dim order, but reverse the dim sizes. If
> working with GDAL alone, I can map data fine with no trouble. But I
> would like to also use NCL for performing calculations. I have tried
> many combinations of array reordering unsuccessfully, ie,
> combination 1:
> var!0="lon"
> var!1="lat"
> varnew=var(lat|:,lon|:)
>
> combination 2,3, and 4:
> varnew=var(::-1,:), or varnew=var(:,::-1), or varnew=var(::-1,::-1)
>
>
> Help and advice would be greatly appreciated.
> thanks,
> Matt
>
> p.s. grib file is here (too big for email and ncl talk):
> ftp://farm.sr.unh.edu/pub/outgoing/matt/ags/ST4.2002010100.01h
> _______________________________________________
> ncl-talk mailing list
> ncl-talk_at_ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Thu Jul 12 2007 - 16:34:41 MDT