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.
the latest version of tds4.2 (beta) should fix this problem. you can download from: http://www.unidata.ucar.edu/software/netcdf-java/ > Well, if a fix was available in a near future that would be absolutely > amazing! > Tell me if you need any help from me, further bug reports or whatever > > Have a nice day! > Fernando > > On Mon, 2010-08-09 at 08:11 -0600, Unidata netCDF Java Support wrote: > > > > Hello John! > > > > > > Apologies for the possible dupe, I had previously replied through > > > webmail during my vacations but never knew if the mail went out > > > correctly. > > > > > > I'm very glad to hear the bug will be addressed in 4.2! > > > I see the current downloadable dev version doesn't yet include that > > > bugfix, I know you must have a lot on your hands. > > > I was wondering if you could tell me what the release schedule for that > > > version is, if there is one. I need to break the news to my boss and > > > having an expected date for a fix may lift his mood a little. :) > > > > ill make one later today and send you an email > > > > > > > > As for using char type instead of binary, I chose to use that as I > > > wanted to minimize type conversions over millions of variables over and > > > over again while performing write and read operations, which could be a > > > problem performance-wise. I may reconsider this, but have to make some > > > benchmarks to justify redesigning how I handle the information > > > internally. > > > > yes, i would benchmark > > > > > > > > Cheers! > > > Fernando > > > > > > On Fri, 2010-07-30 at 14:20 -0600, Unidata netCDF Java Support wrote: > > > > > > > Hi Fernando: > > > > > > > > Yes, it was a bug in my code when the variable sizes are very large. > > > > Unfortunately, I cant retrofit this, so it will only get fixed in the > > > > latest (4.2) code. I will send you a notice when i have that ready. > > > > > > > > BTW, why do you use a char type? it looks like byte would be better. > > > > Although it doesnt much matter in C, in Java we are forced to map to a > > > > java char, which is 16 bits instead of 8, so size is doubled. > > > > > > > > John > > > > > > > > > > > > > Hi John, > > > > > > > > > > I have made a tar.gz compressed netCDF file available at > > > > > > > > > > http://bhusers.upf.edu/~fmuniz/inb/gwaspi/downloads/GT_73010105803CEST.nc.tar.gz > > > > > > > > > > I'm afraid it's quite large, 1,4GB, but that's the nature of the > > > > > beast. > > > > > The variable I'm concerned with is called "genotypes". It's the only > > > > > one > > > > > with 3 dimensions as you will see. > > > > > > > > > > Cheers! > > > > > Fernando > > > > > > > > > > On Fri, 2010-07-30 at 08:35 -0600, Unidata netCDF Java Support wrote: > > > > > > > > > > > Hi Fernando: > > > > > > > > > > > > Can you send us an example file, or a URL to it? thanks > > > > > > > > > > > > John > > > > > > > > > > > > > Full Name: Fernando Mu?iz > > > > > > > Email Address: address@hidden > > > > > > > Organization: Universitat Pompeu Fabra > > > > > > > Package Version: netcdfAll-4.1 > > > > > > > Operating System: Linux (Ubuntu) > > > > > > > Hardware: 7.5GB of JVM ram > > > > > > > Description of problem: Hello! > > > > > > > > > > > > > > I am getting an "java.io.IOException: Negative seek offset" error > > > > > > > when READING a variable with netCDF4.1 java API. > > > > > > > The variable is a D3 array of CHAR datatype, with shape 1053 > > > > > > > (unlimited record), 2618957, 2. > > > > > > > > > > > > > > I get the error when reading subsets of it that are larger than > > > > > > > 409 in the first dimension (e.g 0:410:1, 0:0:1, 0:1:1). > > > > > > > I note that the product of 410*2618957*2 = 2147544740 while > > > > > > > 409*2618957*2 = 2142306826, results that encase 2147483647, > > > > > > > the maximum signed integer in java. > > > > > > > > > > > > > > I'd have to mention that I was encountering problems with this > > > > > > > type of big datasets while WRITING as well in the netCDF4.0, > > > > > > > but this bug was corrected in the netCDF4.1 version. > > > > > > > > > > > > > > I was wondering if you were using a signed integer for indexing > > > > > > > intenally and why not a long or double? > > > > > > > My question is: is this a bug or a unmovable limitation of > > > > > > > netCDF4.1? > > > > > > > > > > > > > > I don't send any code example mainly because this error is > > > > > > > reproducible using the netCDF Tools visualizer. > > > > > > > If you need the data file I'm using, please reply to me and I'll > > > > > > > give you access to a downloadable compressed file. > > > > > > > > > > > > > > Kindly, > > > > > > > Fernando Mu?iz > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ticket Details > > > > > > =================== > > > > > > Ticket ID: KYX-566702 > > > > > > Department: Support netCDF Java > > > > > > Priority: Normal > > > > > > Status: Open > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ticket Details > > > > =================== > > > > Ticket ID: KYX-566702 > > > > Department: Support netCDF Java > > > > Priority: Normal > > > > Status: Open > > > > > > > > > > > > > > > > > > > > > > Ticket Details > > =================== > > Ticket ID: KYX-566702 > > Department: Support netCDF Java > > Priority: High > > Status: Closed > > > > > > Ticket Details =================== Ticket ID: KYX-566702 Department: Support netCDF Java Priority: High Status: Closed