Fortran-interface routines

d@0: d@0: d@0: Fortran-interface routines - FFTW 3.2.1 d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0: d@0:

d@0:

d@0: d@0: d@0: Next: FFTW Constants in Fortran, d@0: Previous: Calling FFTW from Fortran, d@0: Up: Calling FFTW from Fortran d@0:

d@0:

d@0: d@0:

7.1 Fortran-interface routines

d@0: d@0:

Nearly all of the FFTW functions have Fortran-callable equivalents. The d@0: name of the Fortran routine is the same as that of the corresponding C d@0: routine, but with the `fftw_' prefix replaced by `dfftw_'. d@0: (The single and long-double precision versions use `sfftw_' and d@0: `lfftw_', respectively, instead of `fftwf_' and d@0: `fftwl_'.)¹ d@0: d@0:

For the most part, all of the arguments to the functions are the same, d@0: with the following exceptions: d@0: d@0:

plan variables (what would be of type fftw_plan in C), d@0: must be declared as a type that is at least as big as a pointer d@0: (address) on your machine. We recommend using integer*8. d@0: d@0:
Any function that returns a value (e.g. fftw_plan_dft) is d@0: converted into a subroutine. The return value is converted into d@0: an additional first parameter of this subroutine.² d@0: d@0:
The Fortran routines expect multi-dimensional arrays to be in d@0: column-major order, which is the ordinary format of Fortran d@0: arrays (see Multi-dimensional Array Format). They do this d@0: transparently and costlessly simply by reversing the order of the d@0: dimensions passed to FFTW, but this has one important consequence for d@0: multi-dimensional real-complex transforms, discussed below. d@0: d@0:
Wisdom import and export is somewhat more tricky because one cannot d@0: easily pass files or strings between C and Fortran; see Wisdom of Fortran?. d@0: d@0:
Fortran cannot use the fftw_malloc dynamic-allocation routine. d@0: If you want to exploit the SIMD FFTW (see Data Alignment), you'll d@0: need to figure out some other way to ensure that your arrays are at d@0: least 16-byte aligned. d@0: d@0:
Since Fortran 77 does not have data structures, the fftw_iodim d@0: structure from the guru interface (see Guru vector and transform sizes) must be split into separate arguments. In particular, any d@0: fftw_iodim array arguments in the C guru interface become three d@0: integer array arguments (n, is, and os) in the d@0: Fortran guru interface, all of whose lengths should be equal to the d@0: corresponding rank argument. d@0: d@0:
The guru planner interface in Fortran does not do any automatic d@0: translation between column-major and row-major; you are responsible d@0: for setting the strides etcetera to correspond to your Fortran arrays. d@0: However, as a slight bug that we are preserving for backwards d@0: compatibility, the `plan_guru_r2r' in Fortran does reverse the d@0: order of its kind array parameter, so the kind array d@0: of that routine should be in the reverse of the order of the iodim d@0: arrays (see above). d@0: d@0:

d@0: d@0:

In general, you should take care to use Fortran data types that d@0: correspond to (i.e. are the same size as) the C types used by FFTW. If d@0: your C and Fortran compilers are made by the same vendor, the d@0: correspondence is usually straightforward (i.e. integer d@0: corresponds to int, real corresponds to float, d@0: etcetera). The native Fortran double/single-precision complex type d@0: should be compatible with fftw_complex/fftwf_complex. d@0: Such simple correspondences are assumed in the examples below. d@0: d@0: d@0: d@0:

d@0:

Footnotes

[1] Technically, Fortran 77 identifiers are d@0: not allowed to have more than 6 characters, nor may they contain d@0: underscores. Any compiler that enforces this limitation doesn't deserve d@0: to link to FFTW.

d@0: d@0:

[2] The d@0: reason for this is that some Fortran implementations seem to have d@0: trouble with C function return values, and vice versa.

d@0: d@0:

d@0: d@0: d@0: