[gradsusr] wrong data returned by GDS

[Fan Fang]

We'd like to alert you that wrong data can be returned by GDS when using
GrADS expressions for remote analysis.  The particular use case we are
looking at is a simple average over time of a 3-D data array, something
like:

http://hydro1.sci.gsfc.nasa.gov/dods/_expr_{GLDAS_NOAH10SUBP_3H}{ave(soilm1,time=00Z01May1981,time=00Z03May1981)}{13.5:23.5,48.5:54.5,1:1,00Z01May1981:00Z01May1981}.ascii?result

result, [1][1][7][11]
[0][0][0], 29.910242, 26.238947, 27.134758, 27.020594, 28.003983, 29.070147, 28.82657, 29.797018, 35.64337, 30.144405, 29.207136
[0][0][1], 29.826618, 29.838476, 28.972548, 28.466524, 29.172405, 30.278383, 30.268406, 30.101206, 27.801394, 29.78036, 29.379183
[0][0][2], 30.990665, 30.533064, 29.014477, 28.626053, 29.129017, 27.218946, 27.3717, 27.730476, 27.014477, 26.656218, 28.973866
[0][0][3], 30.248077, 28.348171, 27.952454, 27.30996, 27.026241, 23.40676, 26.783747, 27.739277, 26.875324, 27.667511, 27.950476
[0][0][4], 28.968218, 27.320688, 23.698288, 27.290194, 27.100077, 26.604218, 25.810146, 26.362993, 26.035559, 26.762806, 27.149864
[0][0][5], 28.18017, 25.765818, 26.816595, 27.657488, 27.980923, 26.958336, 26.489819, 26.200123, 26.413395, 27.105724, 27.200264
[0][0][6], 9.999E20, 9.999E20, 9.999E20, 9.999E20, 24.032547, 27.266382, 9.999E20, 29.434381, 29.91744, 30.214476, 29.696218



time, [1]
723302.0
lev, [1]
1.0
lat, [7]
48.5, 49.5, 50.5, 51.5, 52.5, 53.5, 54.5
lon, [11]
13.5, 14.5, 15.5, 16.5, 17.5, 18.5, 19.5, 20.5, 21.5, 22.5, 23.5


If we shift the longitude in this URL by half of a degree and request
instead

http://hydro1.sci.gsfc.nasa.gov/dods/_expr_{GLDAS_NOAH10SUBP_3H}{ave(soilm1,time=00Z01May1981,time=00Z03May1981)}{14:24,48.5:54.5,1:1,00Z01May1981:00Z01May1981}.ascii?result

result, [1][1][7][11]
[0][0][0], 29.910242, 26.238947, 27.134758, 27.020594, 28.003983, 29.070147, 28.82657, 29.797018, 35.64337, 30.144405, 29.207136
[0][0][1], 28.484547, 29.826618, 29.838476, 28.972548, 28.466524, 29.172405, 30.278383, 30.268406, 30.101206, 27.801394, 29.78036
[0][0][2], 29.379183, 29.501724, 30.990665, 30.533064, 29.014477, 28.626053, 29.129017, 27.218946, 27.3717, 27.730476, 27.014477
[0][0][3], 26.656218, 28.973866, 29.899324, 30.248077, 28.348171, 27.952454, 27.30996, 27.026241, 23.40676, 26.783747, 27.739277
[0][0][4], 26.875324, 27.667511, 27.950476, 27.3549, 28.968218, 27.320688, 23.698288, 27.290194, 27.100077, 26.604218, 25.810146
[0][0][5], 26.362993, 26.035559, 26.762806, 27.149864, 25.554193, 28.18017, 25.765818, 26.816595, 27.657488, 27.980923, 26.958336
[0][0][6], 26.489819, 26.200123, 26.413395, 27.105724, 27.200264, 25.427088, 9.999E20, 9.999E20, 9.999E20, 9.999E20, 24.032547



time, [1]
723302.0
lev, [1]
1.0
lat, [7]
48.5, 49.5, 50.5, 51.5, 52.5, 53.5, 54.5
lon, [11]
13.5, 14.5, 15.5, 16.5, 17.5, 18.5, 19.5, 20.5, 21.5, 22.5, 23.5


Note that starting from result[0][0][1] wrong values get add in the
front (left) and correct values are pushed back (right) one at a row,
although lat/lon still report the same coordinates as the URL intended.

Note that the data is defined in a (partial) global grid of 1 degree
resolution, centered at (lon, lat) = (-179.5, -59.5) and so on.  We
suspect GDS has implemented an assumption fetching data that is not
consistent with what GrADS is presenting, therefore it indexed the GrADS
data erroneously.

We also find no indications in any GDS documentation that the
expressions shall use the center of grids only.

We use GDS 2.0 and GrADS 2.0.a3.

-Fan