On 2016-01-14 13:16, Alastair McKinstry wrote:
As Nico points out, the two versions (serial, parallel) providedifferent features: notably only the serial version supports compression(and threads), only the parallel version does parallel IO. However any sufficiently complex application will eventually be linkedto _both_. Examples are Paraview / VisIt, which have plugins for reading"all scientific" data, including met data (using netcdf4/hdf5, compression), and the exodus/adios plugins for parallel reads. So, we need to copy the HDF5 method and install libnetcdf*-serial.so* , etc. libraries that are co-installable. These should change SONAMES, symbol suffixes so they can be both linked into the same binary. We probably need libnetcdf-serial-dev and libnetcdf-mpi-dev packages to be co-installable too.
I'd prefer to keep the serial flavor unchanged wrt to upstream, and only customize the mpi flavors (mpich & openmpi).
Upstream only supports enabling parallel support in the main library, not building the parallel library in addition. They support both Automake and CMake, which complicates the proposed changes because we need to support both buildsystems as well for the patch to be eligible for inclusion upstream.
These wishes for parallel netcdf are nice, but so far no one is working on it. I've worked on it in the past, but other tasks demanded my attention causing the project to stall again. This will remain an issue, because I have no need for parallel netcdf. I only maintain the netcdf packages because gdal and other GIS packages depend on it (and no one was actively maintaining the netcdf packages any more).
So if you'd like to see a parallel netcdf library materialize, active contributors are required to make it happen. My requirement is mostly that these changes need to be coordinated with upstream, if netcdf upstream is not interested in those changes I'm not willing to maintain it either.
Kind Regards, Bas