NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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 archives: