<div dir="ltr"><div dir="ltr">On Mon, Apr 15, 2019 at 12:57 AM Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
  <a href="http://www.fftw.org/doc/Memory-Allocation.html" rel="noreferrer" target="_blank">http://www.fftw.org/doc/Memory-Allocation.html</a> 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. <br>
<br>
  The correct fix is to have a VecDuplicate_FFTW_fin() VecDuplicate_FFTW_fout() VecDuplicate_FFTW_bout(). Have MatCreateVecsFFTW_FFTW() <br>
attach the matrix to the new vector with PetscObjectCompose() then the duplicate routines would call PetscObjectQuery to get the matrix and then call <br>
MatCreateVecsFFTW_FFTW() for the duplicate.<br>
<br>
   Pretty easy: Sajid do you want to give it a try?<br>
<br>
But note: one has to be very careful what vectors they duplicate and that they use them in the right places; for example duplicating a fin vector but using it in an fout or bout location and there is no error checking for that in PETSc or FFT. To add error checking one could attach to the FFT vectors a marker indicating if it is fin, fout, bout and then calls to MatMult_FFTW() etc would check the markers on the vectors and error if they are incompatible.<br>
<br>
    Barry<br>
<br>
I find this FFTW model of requiring extra space in the arrays to be a horrifically fragile API. Perhaps I misunderstand it.<br></blockquote><div><br></div><div>I read their documentation differently, so maybe we should discuss this. The only thing their malloc does is alignment. We do the</div><div>padding ourselves, so we could just switch all those statements to PetscMalloc(). The only potential downside is them aligning</div><div>on a bigger offset, which I doubt because we do the same kind of vectorization.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> On Apr 14, 2019, at 8:28 PM, Matthew Knepley via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a>> wrote:<br>
> <br>
> On Sun, Apr 14, 2019 at 9:12 PM Sajid Ali <<a href="mailto:sajidsyed2021@u.northwestern.edu" target="_blank">sajidsyed2021@u.northwestern.edu</a>> wrote:<br>
> Just to confirm, there's no error when running with one rank. The error occurs only with mpirun -np x (x>1). <br>
> <br>
> This is completely broken. I attached a version that will work in parallel, but its ugly.<br>
> <br>
> PETSc People:<br>
> The MatCreateVecsFFT()  calls fftw_malloc()!!! in parallel. What possible motivation could there be?<br>
> This causes a failure because the custom destroy calls fftw_free(). VecDuplicate calls PetscMalloc(),<br>
> but then the custom destroy calls fftw_free() on that thing and chokes on the header we put on all<br>
> allocated blocks. Its not easy to see who wrote the fftw_malloc() lines, but it seems to be at least 8 years<br>
> ago. I can convert them to PetscMalloc(), but do we have any tests that would make us confident that<br>
> this is not wrecking something? Is anyone familiar with this part of the code?<br>
> <br>
>   Matt<br>
>  <br>
> Attaching the error log.<br>
> <br>
> <br>
> -- <br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
> <br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
> <ex_modify.c><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>