On 2016-01-14 13:16, Alastair McKinstry wrote:
As Nico points out, the two versions (serial, parallel) provide
different 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 linked
to _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
