FFTW interface was written by a summer graduate student many years ago. It
was only used occasionally by users. Shall we continue maintain it? If so,
it needs to be updated. For users, using FFTW directly might be better
instead of using this interface.
Hong
On Sun, Apr 14, 2019 at 9:12 PM Matthew
http://www.fftw.org/doc/Memory-Allocation.html The issue isn't really the
fftw_malloc() it is that the current code is broken if the user calls
VecDuplicate() because the new vectors don't have the correct extra space
needed by FFTW and could cause random crashes and incorrect answers.
T
Thanks for the temporary fix.
(PS: I was wondering if it would be trivial to just extend the code to have
four mallocs and create a new function but it looks like the logic is much
more complicated.)
On Sun, Apr 14, 2019 at 9:12 PM Sajid Ali
wrote:
> Just to confirm, there's no error when running with one rank. The error
> occurs only with mpirun -np x (x>1).
>
This is completely broken. I attached a version that will work in parallel,
but its ugly.
PETSc People:
The MatCreateVecsFFT() cal
Hi Matt,
While in theory, that sounds perfect I still get the same error. I'm
attaching a minimal test program which creates 3 vectors x,y,z via the
petsc-fftw interface and a test vector via VecDuplicate and then destroy
all the vectors. Without the test vector everything works fine.
Thank You,
Hi PETSc Developers,
I happen to be a user who needs 4 vectors whose layout is aligned with
FFTW. The usual MatCreateVecsFFTW allows one to make 3 such vectors. To get
around this I call the function twice, once with three vectors, once with
one vector (and 2x NULL). This causes a strange segfault