FFTW 3.3.8: FFTW Execution in Fortran

cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: FFTW 3.3.8: FFTW Execution in Fortran cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167:

cannam@167: cannam@167:

8.3 FFTW Execution in Fortran

cannam@167: cannam@167:

In C, in order to use a plan, one normally calls fftw_execute, cannam@167: which executes the plan to perform the transform on the input/output cannam@167: arrays passed when the plan was created (see Using Plans). The cannam@167: corresponding subroutine call in legacy Fortran is: cannam@167:

cannam@167:

        call dfftw_execute(plan)
cannam@167:

cannam@167: cannam@167: cannam@167:

However, we have had reports that this causes problems with some cannam@167: recent optimizing Fortran compilers. The problem is, because the cannam@167: input/output arrays are not passed as explicit arguments to cannam@167: dfftw_execute, the semantics of Fortran (unlike C) allow the cannam@167: compiler to assume that the input/output arrays are not changed by cannam@167: dfftw_execute. As a consequence, certain compilers end up cannam@167: optimizing out or repositioning the call to dfftw_execute, cannam@167: assuming incorrectly that it does nothing. cannam@167:

cannam@167:

There are various workarounds to this, but the safest and simplest cannam@167: thing is to not use dfftw_execute in Fortran. Instead, use the cannam@167: functions described in New-array Execute Functions, which take cannam@167: the input/output arrays as explicit arguments. For example, if the cannam@167: plan is for a complex-data DFT and was created for the arrays cannam@167: in and out, you would do: cannam@167:

cannam@167:

        call dfftw_execute_dft(plan, in, out)
cannam@167:

cannam@167: cannam@167: cannam@167:

There are a few things to be careful of, however: cannam@167:

cannam@167:

You must use the correct type of execute function, matching the way cannam@167: the plan was created. Complex DFT plans should use cannam@167: dfftw_execute_dft, Real-input (r2c) DFT plans should use use cannam@167: dfftw_execute_dft_r2c, and real-output (c2r) DFT plans should cannam@167: use dfftw_execute_dft_c2r. The various r2r plans should use cannam@167: dfftw_execute_r2r. cannam@167: cannam@167:
You should normally pass the same input/output arrays that were used when cannam@167: creating the plan. This is always safe. cannam@167: cannam@167:
If you pass different input/output arrays compared to cannam@167: those used when creating the plan, you must abide by all the cannam@167: restrictions of the new-array execute functions (see New-array Execute Functions). The most difficult of these, in Fortran, is the cannam@167: requirement that the new arrays have the same alignment as the cannam@167: original arrays, because there seems to be no way in legacy Fortran to obtain cannam@167: guaranteed-aligned arrays (analogous to fftw_malloc in C). You cannam@167: can, of course, use the FFTW_UNALIGNED flag when creating the cannam@167: plan, in which case the plan does not depend on the alignment, but cannam@167: this may sacrifice substantial performance on architectures (like x86) cannam@167: with SIMD instructions (see SIMD alignment and fftw_malloc). cannam@167: cannam@167: cannam@167:

cannam@167: cannam@167:

cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: cannam@167: