Hi Quincey,
>> Ideas/suggestions as to what is going wrong or how to debug this
>> problem would be much appreciated.
>
> Are you using a threadsafe version of HDF5? (i.e. one that is
> configured with the "--enable-threadsafe" option) It's also possible
> that netCDF-4 needs some locking mechanisms also, but that's a
> question for Ed or Russ.
Happy to report that your suggestion appears to solve our problem.
ncbo performs as expected if, and, on SMP systems, only if, we
build HDF5 with --enable-threadsafe. We are still testing to
make sure there are no regressions on our other netCDF operators.
But things look much better, and no re-coding necessary!
This begs some questions:
1. Are there benefits to building HDF without --enable-threadsafe?
If not, can you make it the HDF/netCDF4 default? at least
on multi-core systems?
We have learned, I think, to disable our progams' (NCO's)
threading unless it is linked to threadsafe HDF.
Otherwise users will experience unpredictable NCO failure.
2. How should we test, at NCO compile time, whether the
underlying netCDF4/HDF install is threadsafe?
Thanks,
Charlie
--
Charlie Zender, Department of Earth System Science, UC Irvine
Sab. at CNRS/LGGE-Grenoble until 20080815 :) 011+33+476+824236
Laboratoire de Glaciologie et Géophysique de l'Environnement
54 rue Molière BP 96, 38402 Saint Martin d'Hères Cedex, France
