Re: [netcdf-java] Errors reading certain NetCDF4 data

  • To: Christian Ward-Garrison <cwardgar@xxxxxxxx>
  • Subject: Re: [netcdf-java] Errors reading certain NetCDF4 data
  • From: Antonio Rodriges <antonio.rrz@xxxxxxxxx>
  • Date: Tue, 17 Feb 2015 22:35:22 +0300
Hello,

Sorry for the delayed response.
Many thanks for the jar you have provided. It really reads NetCDF4
files correctly now.

However, I used rechunking with NCO and previous versions of NetCDF
java were able to read the chunked file with the complain that is now
fixed in the version you have provided. I used rechunking mainly to
speed up reading a time series (created 8 x 8 lat x lon blocks) for a
point.

Previous NetCDFJava complained on the file but still was able to read
it. The performance was quite slow for reading a time series for a
point. I thought that the speed was due to issue with the file or
library. The new version you have provided still reads the file as
slow as previous version. I still do not understand whether that is
the expected read speed for the chunked file or still an issue.

Regarding new versions of JRE: I do not totally agree that NetCDF
should keep in pace with the update speed of the Java versions. Many
business software systems written on Java heavily depend on many other
third-party components and have a certain "lag" in keeping with new
Java versions. For example, we are only now able to switch to 1.7
since we have all third-party components that comply with 1.7. If
NetCDF Java in the near future will be avaialble only for 1.8, it will
be again a very difficult story to use it. I think if at least you
would like to provide 1.8 you should at least avoid using new language
syntax specific to 1.8 so that it would be possible to compile the
sources using 1.7

2015-01-17 2:25 GMT+03:00 Christian Ward-Garrison <cwardgar@xxxxxxxx>:
> Hi Antonio,
>
> We haven't yet officially released 4.5.4 (hoping for next week), but I've
> prepared a snapshot release for you [1]. Hopefully it fixes your issue.
>
> Cheers,
> Christian
>
> [1]
> https://drive.google.com/file/d/0B9dBMKQOhIjxYktPeFBHSjR1blE/view?usp=sharing
>
> On Fri, Jan 16, 2015 at 2:24 PM, Ryan May <rmay@xxxxxxxx> wrote:
>>
>> Antonio,
>>
>> One reason we upgrade is that it's very nice as developers to be able to
>> use new features from the language, which are added to make our lives
>> easier, making it simpler (i.e. faster) to add more features. However, the
>> biggest reason we have moved from JRE 6 is that Oracle has stopped
>> supporting it (unless you pay them for extended support):
>> http://www.oracle.com/technetwork/java/eol-135779.html  The last public
>> release of JRE 6 was April of 2013. Since then no bug fixes and, more
>> importantly, no security updates. Given that, it is irresponsible of us not
>> to move to JRE 7, especially since NetCDF-Java powers the THREDDS data
>> server.
>>
>> You should also note that JRE 7 has scheduled end of life (i.e. end of
>> support) for April 2015--at some point following that release we will be
>> forced to move our last supported version to JRE 8.
>>
>> If moving beyond JRE 6 is problematic for you (and you can live with the
>> lack of support and security fixes), NetCDF-Java 4.3 (for JRE 6) can still
>> be downloaded here:
>> http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/documentation.htm
>>
>> Ryan
>>
>> On Fri, Jan 16, 2015 at 10:56 AM, Antonio Rodriges <antonio.rrz@xxxxxxxxx>
>> wrote:
>>>
>>> John,
>>>
>>> I've just downloaded the latest NetCDF-Java 4.5 (since I am not sure
>>> whether I used 4.5.4 or earlier 4.5.* version). The problem is still
>>> there with my file
>>> https://www.dropbox.com/s/xa067an5xogrdyg/2014_ch.nc?dl=0
>>>
>>> By the way, NetCDF-Java 4.5 uses JRE 7 what is quite problematically
>>> for projects still under JRE 6. For a fixed version of NetCDF-Java one
>>> should also migrate all infrastructure to newer JRE what may be even
>>> impossible. Does NetCDF-Java 4.5 leverages JRE 7 specific features so
>>> the decision was taken to abandon JRE 6?
>>>
>>> 2015-01-15 3:39 GMT+03:00 John Caron <caron@xxxxxxxx>:
>>> > Hi Antonio:
>>> >
>>> > I think your problem is fixed in version 4.5.4. In any case its working
>>> > for
>>> > me.
>>> >
>>> > John
>>> >
>>> > On Tue, Jan 13, 2015 at 2:14 AM, Antonio Rodriges
>>> > <antonio.rrz@xxxxxxxxx>
>>> > wrote:
>>> >>
>>> >> Michael,
>>> >>
>>> >> You are not alone.
>>> >> I had the same issue and posted it on this mailing list on early
>>> >> November
>>> >> 2014:
>>> >>
>>> >>
>>> >> http://www.unidata.ucar.edu/support/help/MailArchives/netcdf-java/msg02075.html
>>> >>
>>> >> Some part of my problem:
>>> >> [ucar.nc2.NetcdfFile] DEBUG Using IOSP ucar.nc2.iosp.hdf5.H5iosp
>>> >> [ucar.nc2.iosp.hdf5.H5header] ERROR bad version 72 at filePos 22386
>>> >>
>>> >> I get this error after applying ncks for chunking NetCDF3 file and get
>>> >> NetCDF4 as output.
>>> >>
>>> >> At first I thought that it is an ncks issue, but another trouble like
>>> >> this
>>> >> http://sourceforge.net/p/nco/discussion/9830/thread/152db6f2/
>>> >> suggests of incompatibility of APIs throught NetCDFJava releases, not
>>> >> NCO
>>> >> issue.
>>> >>
>>> >> The trouble is both with NetCDF Java 4.3 and 4.5.
>>> >>
>>> >> I wrote about NetCDF4 issue on early November 2014 and I do not have a
>>> >> workaround or fix from NetCDF Java developers still.
>>> >>
>>> >> 2015-01-13 1:33 GMT+03:00 Gangl, Michael E (398H)
>>> >> <Michael.E.Gangl@xxxxxxxxxxxx>:
>>> >> > We’ve written some wrappers around the NetCDF java packages and are
>>> >> > running into some odd errors. We can successfully read the netCDF4
>>> >> > and
>>> >> > NetCDF4-classic files. But we have a new NetCDF4 file that is
>>> >> > throwing
>>> >> > us
>>> >> > an interesting error:
>>> >> >
>>> >> > java.lang.IllegalStateException: MessageAttribute unknown version 72
>>> >> >         at
>>> >> >
>>> >> > ucar.nc2.iosp.hdf5.H5header$MessageAttribute.read(H5header.java:2645)
>>> >> >         at
>>> >> >
>>> >> >
>>> >> > ucar.nc2.iosp.hdf5.H5header$DataObject.processAttributeInfoMessage(H5header
>>> >> > .java:1579)
>>> >> >         at
>>> >> > ucar.nc2.iosp.hdf5.H5header$DataObject.<init>(H5header.java:1548)
>>> >> >         at
>>> >> > ucar.nc2.iosp.hdf5.H5header$DataObject.<init>(H5header.java:1441)
>>> >> >         at
>>> >> > ucar.nc2.iosp.hdf5.H5header.getDataObject(H5header.java:1291)
>>> >> >         at ucar.nc2.iosp.hdf5.H5header.access$700(H5header.java:48)
>>> >> >         at
>>> >> >
>>> >> > ucar.nc2.iosp.hdf5.H5header$DataObjectFacade.<init>(H5header.java:1334)
>>> >> >         at
>>> >> > ucar.nc2.iosp.hdf5.H5header.readSuperBlock2(H5header.java:301)
>>> >> >         at ucar.nc2.iosp.hdf5.H5header.read(H5header.java:156)
>>> >> >         at ucar.nc2.iosp.hdf5.H5iosp.open(H5iosp.java:86)
>>> >> >         at ucar.nc2.NetcdfFile.<init>(NetcdfFile.java:1110)
>>> >> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:623)
>>> >> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:320)
>>> >> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:290)
>>> >> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:277)
>>> >> >         at ucar.nc2.NetcdfFile.open(NetcdfFile.java:265)
>>> >> >
>>> >> >
>>> >> > The file is provided to us, so I don’t have any idea how it’s being
>>> >> > written, but would that matter? Is this a library issue? Is this
>>> >> > some
>>> >> > configuration on my part that might be causing this issue?
>>> >> >
>>> >> > Thanks,
>>> >> > Mike Gangl
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > netcdf-java mailing list
>>> >> > netcdf-java@xxxxxxxxxxxxxxxx
>>> >> > For list information or to unsubscribe, visit:
>>> >> > http://www.unidata.ucar.edu/mailing_lists/
>>> >>
>>> >> _______________________________________________
>>> >> netcdf-java mailing list
>>> >> netcdf-java@xxxxxxxxxxxxxxxx
>>> >> For list information or to unsubscribe, visit:
>>> >> http://www.unidata.ucar.edu/mailing_lists/
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > netcdf-java mailing list
>>> > netcdf-java@xxxxxxxxxxxxxxxx
>>> > For list information or to unsubscribe, visit:
>>> > http://www.unidata.ucar.edu/mailing_lists/
>>>
>>> _______________________________________________
>>> netcdf-java mailing list
>>> netcdf-java@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>>
>>
>>
>>
>> --
>> Ryan May
>> Software Engineer
>> UCAR/Unidata
>> Boulder, CO
>>
>> _______________________________________________
>> netcdf-java mailing list
>> netcdf-java@xxxxxxxxxxxxxxxx
>> For list information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>
>



  • 2015 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: