This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
We do have a bug fix in version 4.4 about vertical levels sometimes getting flipped. Can you send me a file where you are seeing this problem (previous attachment didnt come through). Also, what version 4.3 are you using? thanks, John > John, > I was wondering if you had a chance to diagnose the RUC grib2 encoded file > sent last week for data discrepancies when read using netcdf-java version 4.2 > and 4.3. > > I was able to find and install the degrib command line utility provided > publicly by the NWS. This provided an independent grib parser for comparing > data values. > > Using the degrib output as a reference lead to the following conclusions: > > 1) If the provided RUC file is read using a 4.2 jar then the data values and > variable names match those of the degrib output > 2) If the grib2 original RUC file is copied using the netcdf 4.3 Tools jar or > the netcdfAll-4.3.jar then when read using a 4.2 or 4.3 jar > 2.a) Data values for the 3-D wind components 'flip' with respect to the > altitude index > Ex: uWindComponentDegrib(alt=n, x=m, y=k) == > uWindComponentNetcdfCopied(alt=n, x=m, y=k) => false > uWindComponentDegrib (alt=n, x=m, y=k) == uWindComponentNetcdfCopied > (alt=50-n+1, x=m, y=k) => true > 2.b) Variable names change > > If you could please provide some insight as to whether these conclusions are > plausible I would very much appreciate it. The degrib utility is independent > of netcdf and its results indicate that the 4.2 jar is providing the correct > data values, in contradiction to our discussion of 4.2/4.3 grib handling. I > can provide additional data upon request, thanks > > Kevin > > > -----Original Message----- > From: Unidata netCDF Java Support [mailto:address@hidden] > Sent: Friday, January 17, 2014 10:32 AM > To: Ray, Kevin M > Cc: address@hidden > Subject: [netCDFJava #QAX-163810]: Data Value Discrepancies Between Netcdf > 4.2 and 4.3 > > Very likely! > > > John, > > I have found some projects that were utilizing a netcdf java 4.0 jar. Would > > that version be subject to the same behavior we are discussing? thanks, > > > > Sincerely > > Kevin > > > > -----Original Message----- > > From: Ray, Kevin M > > Sent: Thursday, January 16, 2014 12:43 PM > > To: 'address@hidden' > > Subject: RE: [netCDFJava #QAX-163810]: Data Value Discrepancies Between > > Netcdf 4.2 and 4.3 > > > > John, > > Here is a RUC file and associated gbx file for which data values were found > > to differ. Please let me know if you require anything else, > > > > Kevin > > > > -----Original Message----- > > From: Unidata netCDF Java Support [mailto:address@hidden] > > Sent: Thursday, January 16, 2014 12:41 PM > > To: Ray, Kevin M > > Cc: address@hidden > > Subject: [netCDFJava #QAX-163810]: Data Value Discrepancies Between Netcdf > > 4.2 and 4.3 > > > > > John, > > > Thank you for getting back. > > > > > > I will take your advice and start the process of updating our netcdf-java > > > dependencies to version 4.3. > > > > > > In the meantime would you mind examining a specific file to hopefully > > > diagnose the nature of the discrepancies? I have been copying the file > > > using custom java code (adhering to the previously referenced tutorials) > > > and the netcdf tools UI jar (versions 4.2 and 4.3). My verification > > > process has been bringing the file's data into MATLAB using the freely > > > available nctoolbox. The data values brought into MATLAB were compared to > > > the data values parsed by the custom java code by dumping data values > > > into a csv file, and found to match in all instances. What did not match > > > was the data values between original files and those that had been copied > > > using a 4.3 netcdf jar. > > > > > > I'm afraid that I do not have immediate access to an independent > > > verification process for the files under consideration, but I will look > > > around and try to see if there is one available. In the meantime what > > > would be the best way for me to get these files to you? Thanks! > > > > if too big for email, could use an ftp or web server or dropbox? > > > > > > Ticket Details > > =================== > > Ticket ID: QAX-163810 > > Department: Support netCDF Java > > Priority: Normal > > Status: Open > > > > > > > Ticket Details > =================== > Ticket ID: QAX-163810 > Department: Support netCDF Java > Priority: Normal > Status: Open > > Ticket Details =================== Ticket ID: QAX-163810 Department: Support netCDF Java Priority: Normal Status: Open