std::exception

[johnwilkin]

Deep inside nj_time when it is calling ncdataset I am getting the error below, but only after the code has been looping through about 100 times. If I exit Matlab and start over it's fine.

d = nj_time(f,'ocean_time'); 30 result=[]; Caught "std::exception" Exception message is: Message Catalog MATLAB:services was not loaded from the file. Please check file location, format or contents

[hohonuuli]

@johnwilkin Can you post a link to the data set thats triggering this as well as a full code example so that we can reproduce the issue. Thanks

[johnwilkin]

Brian,

I will try to trip it down to a minimal set of code that throws the error. As it stands the code is a complicated mess of analysis and plotting that calls many functions - I don't think those functions are at the heart of the issue because the error is always occurring inside ncdataset.

John.

John L Wilkin | jwilkin@rutgers.edu | ph: +1-609-630-0559 web: marine.rutgers.edu/~wilkin | cal: tinyurl.com/jwilkincalendar

On Wed, Jul 9, 2014 at 7:20 PM, Brian Schlining notifications@github.com wrote:

@johnwilkin https://github.com/johnwilkin Can you post a link to the data set thats triggering this as well as a full code example so that we can reproduce the issue. Thanks

Reply to this email directly or view it on GitHub https://github.com/nctoolbox/nctoolbox/issues/47#issuecomment-48547749.

[johnwilkin]

Brian,

The data file and code is at:

https://www.dropbox.com/sh/e1wlly4gs7kr3av/AABPdd6bY54-OAc5EnHfT78Na

I put it in a loop and get ...

for k=1:10000 exception_in_nctoolbox end Caught "std::exception" Exception message is: Message Catalog MATLAB:services was not loaded from the file. Please check file location, format or contents k k = 572

Once the error arises I get this when trying to execute a command in the shell:

!cp /Users/wilkin/Dropbox/sandbox/roms_genslice.m exception Error using ! Unexpected system error: pty[450]: pipe [24] Too many open files

Thanks, John.

John L Wilkin | jwilkin@rutgers.edu | ph: +1-609-630-0559 web: marine.rutgers.edu/~wilkin | cal: tinyurl.com/jwilkincalendar

On Thu, Jul 10, 2014 at 10:01 AM, John Wilkin john.wilkin@alum.mit.edu wrote:

Brian,

I will try to trip it down to a minimal set of code that throws the error. As it stands the code is a complicated mess of analysis and plotting that calls many functions - I don't think those functions are at the heart of the issue because the error is always occurring inside ncdataset.

John.

John L Wilkin | jwilkin@rutgers.edu | ph: +1-609-630-0559 web: marine.rutgers.edu/~wilkin | cal: tinyurl.com/jwilkincalendar

On Wed, Jul 9, 2014 at 7:20 PM, Brian Schlining notifications@github.com wrote:

@johnwilkin https://github.com/johnwilkin Can you post a link to the data set thats triggering this as well as a full code example so that we can reproduce the issue. Thanks

Reply to this email directly or view it on GitHub https://github.com/nctoolbox/nctoolbox/issues/47#issuecomment-48547749.

[hohonuuli]

OK. Yep. It's a bug that I can duplicate. I ran the following:

for i = 1:10000 
  fprintf(1, '%i\n', i);
  exception_in_nctoolbox;
end

It crashed with:

...
711
712
713
714
Caught "std::exception" Exception message is:
Message Catalog MATLAB:services was not loaded from the file. Please check file location, format or contents

[hohonuuli]

Attempted to duplicate with:

for i = 1:10000; 
  fprintf(1, '%i\n', i);
  nc = ncgeodataset('romsfit_TSClim_Vel_Jason_mon_clim_jw.nc'); 
  v = nc.data('salt');
end

Ran fine. Completed all 10,000 iterations.

[hohonuuli]

Attempted to duplicate error with:

for i = 1:10000
  fprintf(1, '%i\n', i);
  nc = ncgeodataset('romsfit_TSClim_Vel_Jason_mon_clim_jw.nc'); 
  v = nc.geovariable('salt');
  g = v.grid(1, :);
end

This duplicates the error with:

...
797
798
799
Caught "std::exception" Exception message is:
Message Catalog MATLAB:services was not loaded from the file. Please check file location, format or contents

[hohonuuli]

Attempted to duplicate error with a modification of the above code:

for i = 1:10000
  fprintf(1, '%i\n', i);
  nc = ncgeodataset('romsfit_TSClim_Vel_Jason_mon_clim_jw.nc'); 
  v = nc.geovariable('salt');
  % REMOVED CALL TO GRID
end

This runs fine. No error is thrown.

[hohonuuli]

I believe the error is caused by having too many file handles open. Looking through the code I don't see any obvious place where resources are remaining open. It may be related to Issue #24 though.

[johnwilkin]

Brian,

I'm not surprised the issue is buried in the grid processing. I suspected the grid_interop facility, but I don't think the v.grid syntax is getting too deep into the CDM specs for interoperability.

Have a solution?

Thanks, John.

John L Wilkin | jwilkin@rutgers.edu | ph: +1-609-630-0559 web: marine.rutgers.edu/~wilkin | cal: tinyurl.com/jwilkincalendar

On Wed, Jul 16, 2014 at 3:50 PM, Brian Schlining notifications@github.com wrote:

Attempted to duplicate error with a modification of the above code:

for i = 1:10000 fprintf(1, '%i\n', i); nc = ncgeodataset('romsfitTSClim Vel_Jason_mon_clim_jw.nc'); v = nc.geovariable('salt'); % REMOVED CALL TO GRID end

This runs fine. No error is thrown.

Reply to this email directly or view it on GitHub https://github.com/nctoolbox/nctoolbox/issues/47#issuecomment-49217245.

[hohonuuli]

I modified roms_genslice.m and removed the call to close(nc). When I run:

for i = 1:10000 
  fprintf(1, '%i\n', i);
  exception_in_nctoolbox;
end

I get the following error:

...
710
711
712
Error using subsref
No appropriate method, property, or field gettimename for class ncvariable.
Attempted to access d(1); index out of bounds because numel(d)=0.

Error in exception_in_nctoolbox (line 11)
timTrk = d(mon);

Unfortunately, I don't have a workaround at the moment. The course of action we're taking is to remove the usage of subsref, which really mucks things up. I've started work on this in develop branch on github, but have not yet added the ncgeodataset.m functionality to geocdm.m.

[hohonuuli]

@johnwilkin Sorry, no solution yet. I've got to switch gears for today, but I'll keep poking at it this week.

[johnwilkin]

I don't know geocdm.m

Am I out of date with nctoolbox?

John L Wilkin | jwilkin@rutgers.edu | ph: +1-609-630-0559 web: marine.rutgers.edu/~wilkin | cal: tinyurl.com/jwilkincalendar

On Wed, Jul 16, 2014 at 4:01 PM, Brian Schlining notifications@github.com wrote:

I modified roms_genslice.m and removed the call to close(nc). When I run:

for i = 1:10000 fprintf(1, '%i\n', i); exception_in_nctoolbox; end

I get the following error:

... 710 711 712 Error using subsref No appropriate method, property, or field gettimename for class ncvariable. Attempted to access d(1); index out of bounds because numel(d)=0.

Error in exception_in_nctoolbox (line 11) timTrk = d(mon);

Unfortunately, I don't have a workaround at the moment. The course of action we're taking is to remove the usage of subsref, which really mucks things up. I've started work on this in develop branch on github, but have not yet added the ncgeodataset.m functionality to geocdm.m.

Reply to this email directly or view it on GitHub https://github.com/nctoolbox/nctoolbox/issues/47#issuecomment-49218736.

[hohonuuli]

No, I'm implementing stuff laid out in our roadmap (Issue #46). We're (well ... me) are in process of removing the calls like nc{'foo'}(1, 2, 1:100) and replacing it with calls like c.mdata('foo', 1, 2, 1:100). Using the former syntax involves some very convoluted logic inside a method called subsref and makes very messy, hard-to-debug code.

The development code is in github on the develop branch and isn't ready for real use yet.

In other news, I spoke with the Mathworks guys today about the possibility of making nctoolbox a Mathworks support toolbox. So maybe we'll get some other engineers to help with maintenance and development.

[johnwilkin]

Brian,

Now I'm glad I avoided delving into the {} syntax. The CDM interoperability is the thing I like most about nctoolbox so that's great to see that progressing.

I had a telecon with Mathworks folk on June 27: Bruce Tannenbaum, Ellen Johnson and Kelly Luetkemeyer. Bruce wanted to poll me on nctoolbox and the notion of it supported within Matlab. I did my best to extoll the virtues of having a toolbox that sits on top of the lower level netcdf functionality provided by Matlab (which I never use directly) that delivers the interoperability we all like with opendap/thredds etc that exploit metadata standards.

John.

John L Wilkin | jwilkin@rutgers.edu | ph: +1-609-630-0559 web: marine.rutgers.edu/~wilkin | cal: tinyurl.com/jwilkincalendar

On Wed, Jul 16, 2014 at 4:13 PM, Brian Schlining notifications@github.com wrote:

No, I'm implementing stuff laid out in our roadmap (Issue #46). We're (well ... me) are in process of removing the calls like nc{'foo'}(1, 2, 1:100) and replacing it with calls like c.mdata('foo', 1, 2, 1:100). Using the former syntax involves some very convoluted logic inside a method called subsref and makes very messy, hard-to-debug code.

In other news, I spoke with the Mathworks guys today about the possibility of making nctoolbox a Mathworks support toolbox. So maybe we'll get some other engineers to help with maintenance and development.

Reply to this email directly or view it on GitHub.

[rsignell-usgs]

@johnwilkin is running this on his MacOS machine, and he found out the maximum number of open files is 256. He is going to see if increasing the maximum number of open files using the instructions here http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/#Mac-OS-X will help band-aid fix the problem, but we really should try to figure out why so many files are getting opened. The script should just open the NetCDF file once, and close it once.

Would enabling the matlab profiler and then running the test give us clues about what is opening all these files?

[hohonuuli]

Can he (@johnwilkin) post a code sample that replicates this problem? I suspect the issue is in ncgeodataset. Some operations that it performs opens a new Netcdf object rather than sharing a reference to the already open object.

[rsignell-usgs]

https://github.com/nctoolbox/nctoolbox/issues/47#issuecomment-49216916