Hey,
Mani's build included
--with-threadcomm --with-pthreadclasses --with-openmp
which seems the be the cause of the problem. Without these flags, the
problem disappears and results are correct. If I remember correctly,
this is a more fundamental problem in threadcomm rather than specific to
the ViennaCL bindings, yet we clearly need to fix it.
[repost from petsc-maint]
Evidently threads are a liability right now. Do you know what caused
this behavior so we can avoid it in the future?
Unfortunately I don't know what exactly is causing the problem. My best
guess is that one of the sys-calls inside threadcomm is in conflict with
the internals of the OpenCL runtime. I'll see whether I can reproduce
this on my machine, then I can incrementally disable parts of threadcomm
until I found the cause.
Okay, I could reproduce this problem on my machine: A configuration
including
--with-threadcomm --with-pthreadclasses --with-openmp
fails, while
--with-threadcomm --with-pthreadclasses
works. Note that all runs are single-threaded, so it is only the
presence of -fopenmp which screws things up. The most immediate 'fix' is
to prevent the combination of OpenMP and OpenCL at the configure stage.
The problem does not show up in a fresh build with CUDA and CUSP, at
least not when using the standard ComputeResidual() based on VecGetArray().
Best regards,
Karli
