-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In-place real-to-complex FFTs #65
Conversation
Looks great, thanks for this very nice work. I agree that it would be better to modify the definition of |
Codecov Report
@@ Coverage Diff @@
## master #65 +/- ##
==========================================
- Coverage 98.13% 96.97% -1.16%
==========================================
Files 10 11 +1
Lines 429 529 +100
==========================================
+ Hits 421 513 +92
- Misses 8 16 +8
|
Thanks again for this very nice addition. I took the liberty of doing some minor modifications, in particular simplifying the logic of allocating arrays for in-place transforms. As for the code duplication between ManyPencilArrayRFFT!{T,N,M} <: AbstractManyPencilArray{N,M} and remove most of the methods currently defined for |
Great ! Things will look much cleaner with your modifications. They should also ease the possibility to allocate data for a BRFFT!, which wasn't covered in my commits. Test sets might need to be broadened for RFFT! and BRFFT! Many thanks to you for these nice libraries that ease so much the use of MPI for arrays and FFTs. |
This PR is an attempt to address the issue #21, based on FFTW.jl
The following modifications are made:
RFFT!
andBRFFT!
transforms in Transforms/r2c.jlplan_rfft!
andplan_brfft!
extending FFTW.jl for the creation of plans for in-place rfft! and brfft! in Transforms/r2c.jlManyPencilArrayRFFT!
container in multiarrays_r2c.jl container which adaptsManyPencilArray
. In this part, a real data vector must reinterpreted as a complex vector. This is done usingconvert
of a pointer from Float to Complex andunsafe_wrap
, instead of using the Juliareinterpret
function, as suggested in this FFTW pull-request. In future, it might be more appropriate to redefineManyPencilArray
or create a supertype toManyPencilArrayRFFT!
andManyPencilArray
directly in PencilArrays.jl to avoid multiple method redefinitions. For now I didn't want to make separate PRs for testing purposes.ManyPencilArrayRFFT!
is allocated by aPencilFFTPlan
whenever appropriate in allocate.jl.RFFT!
forward and backward. In the mean time, the final scaling of the backward operations is separated from the actual backward transforms (see e.g. the difference between anifft
and abfft
in AbstractFFTs.jl), and a new functionbmul!
is provided in addition to the existingmul!
andldiv!
.RFFT!
againstRFFT