> 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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.