use embeded fftw3 as a subpackage #9
Conversation
|
Thank you for the patch. I will have a look on it. However, it might be a bit more difficult, since PFFT is also a submodule of PNFFT and ScaFaCoS. ScaFaCoS comes with its own FFTW clone -- but there we must prefix all FFTW functions with fcs_fftw_ in order to avoid linking errors. I have to think of a nice approach that allows PFFT to come with its own FFTW and PNFFT to come with its own FFTW and PFFT. The solution must be compatible with ScaFaCoS, that comes with its own FFTW, PFFT and PNFFT. In addition, it should be possible that the user provides its own versions of the dependencies via CFLAGS and LDFLAGS. |
|
Any ideas are appreciated. |
|
May I ask why PFFT has a FFTW, PNFFT has another FFTW, and ScaFaCoS has a third FFTW? What is the difference between these FFTWs? |
|
FYI, a requirement on a patched version of FFTW would seriously hinder any attempts to package these pieces of software for Linux. |
|
on the PFFT side, an alternative is to give FFTW the ability to accept additional planners. That may be easier to get accepted than, supplying with new planners that FFTW upstream doesn't make use of. What customization to FFTW does PNFFT and ScaFaCoS require? |
|
I agree with @ghisvail -- was bitten by this before. |
This hugely simplifies the building process of pfft. Since the new planners are unlikely to be included in next release of FFTW, it makes sense to just ship in a release the patched version of FFTW that is known to work with PFFT. touch fftw3/Changelog
But the result is garbage.
however the round trip is correct. So looks like we are doing some transpose incorrectly but consistently.
But without it the single tranform was wrong anyways.
…it data, not part of the pfft kernel)
The old head breaks pfft-python everywhere with a crash in local_size_remap_nd_transposed
This fixed all cases but the PADDED r2C and likely the shifted transforms. The problem with the padded r2c transforms is that somehow the last axis local_ni is not padded. It should be a trivial fix? I am lost here, because the size is actually computed outside the remap routines by partrafo.c The routines looked generic enough to support any decompositions, including 2d on 2d and 3d on 3d.
It appears that we shall prefer out of place global_transp as much as possible. The FFTW_PRESERVE_INPUT flag is added to signify that the transform must be preserving input; it should have been added automatically. Also expanding the code branches to make it easier to parse what is actually done in different cases.
3 participants
This hugely simplifies the building process of pfft. Since the new
planners are unlikely to be included in next release of FFTW in any short term, it
makes sense to just ship in a release the patched version of FFTW
that is known to work with PFFT.
This currently requires --enable-mpi on the configure scripts. threading support is untested.