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

  • To: Antonio Rodriges <antonio.rrz@xxxxxxxxx>
  • Subject: Re: [netcdf-java] Errors reading certain NetCDF4 data
  • From: Christian Ward-Garrison <cwardgar@xxxxxxxx>
  • Date: Wed, 18 Feb 2015 15:56:52 -0700
Hi Antonio,

"Slow" is a vague adjective to describe read speed. What is your definition
of slow? I spent some time toying around with your example file in ToolsUI
and the performance seemed okay. Even the Grid Viewer animation (very I/O
intensive) showed no unusual lag.

I suspect the issue is related to your particular read pattern and the
layout of the data within the file. Are you accessing data that is
contiguous or interspersed throughout? The latter case will yield much
worse performance, as it cannot exploit data locality.

Cheers,
Christian

On Tue, Feb 17, 2015 at 12:35 PM, Antonio Rodriges <antonio.rrz@xxxxxxxxx>
wrote:

> 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: