Sajid,
Where is the pull request for this? Better to get in the Bibuckit pull
request system then have it drag out and have code change around. So please go
ahead and post the pull request. It looked pretty much done the last time I saw
it.
Barry
> On Apr 17, 2019, at 9:32 AM,
Hi Matt/Barry,
I've implemented this for 1D-complex-mpi vec and tested it.
Here is the modified source file ->
https://bitbucket.org/sajid__ali/petsc/src/86fb19b57a7c4f8f42644e5160d2afbdc5e03639/src/mat/impls/fft/fftw/fftw.c
Functions definitions at
Hi Barry/Matt,
Since VecDuplicate calls v->ops->duplicate, can't we just add custom
duplicate ops to the (f_in/f_out/b_out) vectors when they are created via
MatCreateFFTW? (just like the custom destroy ops are defined)
Also, what is the PetscObjectStateIncrease function doing ?
Thank You,
> On Apr 15, 2019, at 6:57 PM, Matthew Knepley wrote:
>
> On Mon, Apr 15, 2019 at 2:44 PM Smith, Barry F. wrote:
>
> There are two distinct issues here.
>
> 1) the use of fftw_malloc(). This is a relatively minor issue. This is
> causing the crash in the code because VecDuplicate()
There are two distinct issues here.
1) the use of fftw_malloc(). This is a relatively minor issue. This is causing
the crash in the code because VecDuplicate() uses PetscMalloc() to obtain the
array but when the array is freed fftw_malloc() is called on it.
2) the padding that FFTW needs
Hi Barry & Matt,
I'd be happy to contribute a patch once I understand what's going on.
@Matt, Where is the padding occurring? In the VecCreateFFTW I see that each
process looks up the dimension of array it's supposed to hold and asks for
memory to hold that via fftw_malloc (which as you say is
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
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.
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()
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
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
12 matches
Mail list logo
