Jeff Whitaker

It does work, it's just slow since the code will call nc_get_vars when the sequence of integers is evenly spaced (i.e. it fits into a strided read). I gather you...

Pull request #681 does not convert sequences of indices to slices unless step=1. For your example above this means that one `nc_get_vara` call will be made for each element of...

Pull request #683 builds on #681 by also converting strided slices (i.e `var[::2]`) to individual calls to nc_get_vara. An arbitrary threshold of 1000 is included, if the number of calls...

I removed the threshold, so that nc_get_vars is never called since tests showed that even 10,000 calls to nc_get_vara was faster than a single call to nc_get_vars.

I'm pretty sure this is a netcdf-c issue. For some reason, the 'endian-ness' of the variable is lost when the dataset is closed and re-opened. I suggest creating a netcdf-c...

Here's a c program that appears to trigger the problem: ```c #include int main() { int i, iret, dimid, varid, ncid; int data[10]; for (i = 0; i < 10;...

Yikes! Perhaps the python module should issue a warning if it detects hdf5 1.10. At the very least, we should change the build instructions.

I've got nothing - but I suspect that you are right that it has something to do with the MPI libraries that get loaded when you import netCDF4. Can you...

You could also test this theory by trying to import mpi4py to see if that crashes the IDE.

OK, that's interesting. so netCDF4 imports mpi4py, and apparently that causes the crash (but only in the IDE, not in the terminal).