Re: [thredds] Stride not working with ncml aggregation

Thanks John. I am glad it was useful.

Upendra


On 7/2/2011 1:56 PM, John Caron wrote:
Hi Upendra:

Yes you are right. There a bug in reading strided subsets of joinExisting aggregations. Ill have a fix out early next week. Thanks for seeing that and your very fine test to reproduce it!

John

On 7/1/2011 9:27 AM, Upendra.Dadi@xxxxxxxx wrote:
Hi,
I am getting wrong results with OpenDAP requests on ncml aggregation when using strides. THREDDS sometimes give an error message and sometimes the output is plain wrong. It seems to be working fine with regular netCDF files. To demonstrate this I have created two files the first file is a regular netcdf file with one variable (with name "time") and one dimension of size 14: http://data.nodc.noaa.gov/thredds/catalog/testdata/strides/catalog.html?dataset=testdata/strides/agg.nc
The values for the variable range from 1 to 14.

The second is an ncml aggregation which is equivalent to the first file, aggregated along the single dimension. The ncml aggregation has four files- first file with dimension 5, second with 3, third with 2 and fourth with 4 (adds up to 14): http://data.nodc.noaa.gov/thredds/catalog/testdata/strides/catalog.html?dataset=testdata/strides/agg_thredds.ncml

Now, when I issue OpenDAP requests with strides, I get the following output

Request Output from the regular NetCDF Output from the NCML aggregation(- - - - - | - - - | - - | - - - -) ------------ --------------------------------------------- ------------------------------------------------- time[0:1:13] 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 (correct) time[0:2:13] 1, 3, 5, 7, 9, 11, 13 1, 3, 5, 7, 9, 11, 13 (correct) time[0:3:13] 1, 4, 7, 10, 13 1, 4, 8, 12, 0 (incorrect) time[0:4:13] 1, 5, 9, 13 message = "NcSDArray java.lang.ArrayIndexOutOfBoundsException=null for request= NcSDArray read time time(0,4,13) ... time[0:5:13] 1, 6, 11 1, 6, 11 (correct) time[0:6:13] 1, 7, 13 1, 0, 0 (incorrect) time[0:7:13] 1, 8 1, 0 (incorrect) time[0:8:13] 1, 9 1, 9 (correct) time[0:9:13] 1, 10 1, 0 (incorrect) time[0:10:13] 1, 11 1, 11 (correct) time[0:11:13] 1, 12 1, 0 (incorrect) time[0:12:13] 1, 13 1, 0 (incorrect) time[0:13:13] 1, 14 1, 0 (incorrect) time[0:14:13] 1 1 (correct)

There seems to be some pattern to whenever it gives incorrect results. After jumping from one dataset to a subsequent one in the aggregation, if the new index doesn't correspond to the first value in the subsequent dataset, it gives incorrect results.

Upendra

_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/

_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/