[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #HRB-457979]: Error accessing netcdf file via Matlab, in particular a CF-1.6 convention file.

Hi Dan,

I spoke with our DAP developer and here's what he had to say:

````

This has come up a couple of times very recently (probably
from same original source). Anyway, I have added fixes in the dap4
code to handle this. I have not yet figured out how to deal
with this in the DAP2 code. Note that for us, we need to handle it
both in the netcdf-c library and in the thredds server.
=Dennis
p.s. In looking at the DAP2 spec, it is unclear if this is even legal.
but IMO we need to handle it anyway.
````

So, it looks like this is definitely something we should address on our end; 
thanks for the bug report.  I'll try to follow up with you when it looks like 
we have a fix in place.

-Ward

> I'm working to track down a problem that PeterC is having, trying to read
> data from NetCDF files (served via DAP) that contain 0-length arrays,
> He's using Matlab but thru their NetCDF interface.  For the record the
> problem is the same accessing the data via Hyrax or TDS.
> 
> Anyway, here's an example Hyrax URL:
> 
> http://satdat4.gso.uri.edu/opendap/ARGO/dac/aoml/15854/15854_prof.nc
> 
> and TDS URL:
> 
> http://satdat4.gso.uri.edu/thredds/dodsC/test/15854_prof.nc.html
> 
> note: the very last variables contain zero-length dimensions.
> 
> His initial workaround once we updated the server was to try to read a
> few of the valid variables, like LATITUDE, LONGITUDE.  AsciiVal works
> fine as such, but using the nc_read() in Matlab crashes hard.
> 
> So, I downloaded the latest netcdf-c api and wrote a very simple c
> program to open and try to read LATITUDE and LONGITUDE.   Opening the
> file, inquiring about the variables, and closing the works fine, but
> reading these valid variables doesn't.   This is the error
> returned:
> 
> [Dans-MBP:local/src/argo-test] dan% gcc -o prof-test argo-prof-test.c
> -I/usr/local/include -L/usr/local/lib -lnetcdf
> [Dans-MBP:local/src/argo-test] dan% ./prof-test
> dim->dim.declsize0 > 0
> 
> Assertion failed: (dappanic("dim->dim.declsize0 > 0")), function
> dapvar2projection, file constraints.c, line 721.
> Abort
> 
> It appears that the NetCDF API is testing all the variables for
> validity, not just the requested variable.
> 
> Also, if I run this against the file itself, not via the URL, it works
> fine.
> 
> We've reported the bug to MathWorks though I'm not sure how far they'll
> get, eventually they'll end up at Unidata.   Granted, files like this
> with 0-length variables are BS IMO, but if it works accessing thru the
> file-API it's hard to explain why it doesn't via DAP access.
> 
> Here's my sample program, can't get much simpler than this.
> 
> and here's that data file.
> 
> No idea why they create files with zero-length dimensioned arrays but
> the NetCDF API does not complain when accessing the file directly,
> but does when trying to retrieve data via the DAP even though we aren't
> trying to access the zero-length variables themselves.
> 
> Dan
> 
> 
> 


Ticket Details
===================
Ticket ID: HRB-457979
Department: Support netCDF
Priority: Normal
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.