cannam@127: @node Calling FFTW from Modern Fortran, Calling FFTW from Legacy Fortran, Distributed-memory FFTW with MPI, Top
cannam@127: @chapter Calling FFTW from Modern Fortran
cannam@127: @cindex Fortran interface
cannam@127: 
cannam@127: Fortran 2003 standardized ways for Fortran code to call C libraries,
cannam@127: and this allows us to support a direct translation of the FFTW C API
cannam@127: into Fortran.  Compared to the legacy Fortran 77 interface
cannam@127: (@pxref{Calling FFTW from Legacy Fortran}), this direct interface
cannam@127: offers many advantages, especially compile-time type-checking and
cannam@127: aligned memory allocation.  As of this writing, support for these C
cannam@127: interoperability features seems widespread, having been implemented in
cannam@127: nearly all major Fortran compilers (e.g. GNU, Intel, IBM,
cannam@127: Oracle/Solaris, Portland Group, NAG).
cannam@127: @cindex portability
cannam@127: 
cannam@127: This chapter documents that interface.  For the most part, since this
cannam@127: interface allows Fortran to call the C interface directly, the usage
cannam@127: is identical to C translated to Fortran syntax.  However, there are a
cannam@127: few subtle points such as memory allocation, wisdom, and data types
cannam@127: that deserve closer attention.
cannam@127: 
cannam@127: @menu
cannam@127: * Overview of Fortran interface::
cannam@127: * Reversing array dimensions::
cannam@127: * FFTW Fortran type reference::
cannam@127: * Plan execution in Fortran::
cannam@127: * Allocating aligned memory in Fortran::
cannam@127: * Accessing the wisdom API from Fortran::
cannam@127: * Defining an FFTW module::
cannam@127: @end menu
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node Overview of Fortran interface, Reversing array dimensions, Calling FFTW from Modern Fortran, Calling FFTW from Modern Fortran
cannam@127: @section Overview of Fortran interface
cannam@127: 
cannam@127: FFTW provides a file @code{fftw3.f03} that defines Fortran 2003
cannam@127: interfaces for all of its C routines, except for the MPI routines
cannam@127: described elsewhere, which can be found in the same directory as
cannam@127: @code{fftw3.h} (the C header file).  In any Fortran subroutine where
cannam@127: you want to use FFTW functions, you should begin with:
cannam@127: 
cannam@127: @cindex iso_c_binding
cannam@127: @example
cannam@127:   use, intrinsic :: iso_c_binding 
cannam@127:   include 'fftw3.f03'
cannam@127: @end example
cannam@127: 
cannam@127: This includes the interface definitions and the standard
cannam@127: @code{iso_c_binding} module (which defines the equivalents of C
cannam@127: types).  You can also put the FFTW functions into a module if you
cannam@127: prefer (@pxref{Defining an FFTW module}).
cannam@127: 
cannam@127: At this point, you can now call anything in the FFTW C interface
cannam@127: directly, almost exactly as in C other than minor changes in syntax.
cannam@127: For example:
cannam@127: 
cannam@127: @findex fftw_plan_dft_2d
cannam@127: @findex fftw_execute_dft
cannam@127: @findex fftw_destroy_plan
cannam@127: @example
cannam@127:   type(C_PTR) :: plan
cannam@127:   complex(C_DOUBLE_COMPLEX), dimension(1024,1000) :: in, out
cannam@127:   plan = fftw_plan_dft_2d(1000,1024, in,out, FFTW_FORWARD,FFTW_ESTIMATE)
cannam@127:   ...
cannam@127:   call fftw_execute_dft(plan, in, out)
cannam@127:   ...
cannam@127:   call fftw_destroy_plan(plan)
cannam@127: @end example
cannam@127: 
cannam@127: A few important things to keep in mind are:
cannam@127: 
cannam@127: @itemize @bullet
cannam@127: 
cannam@127: @item
cannam@127: @tindex fftw_complex
cannam@127: @ctindex C_PTR
cannam@127: @ctindex C_INT
cannam@127: @ctindex C_DOUBLE
cannam@127: @ctindex C_DOUBLE_COMPLEX
cannam@127: FFTW plans are @code{type(C_PTR)}.  Other C types are mapped in the
cannam@127: obvious way via the @code{iso_c_binding} standard: @code{int} turns
cannam@127: into @code{integer(C_INT)}, @code{fftw_complex} turns into
cannam@127: @code{complex(C_DOUBLE_COMPLEX)}, @code{double} turns into
cannam@127: @code{real(C_DOUBLE)}, and so on. @xref{FFTW Fortran type reference}.
cannam@127: 
cannam@127: @item
cannam@127: Functions in C become functions in Fortran if they have a return value,
cannam@127: and subroutines in Fortran otherwise.
cannam@127: 
cannam@127: @item
cannam@127: The ordering of the Fortran array dimensions must be @emph{reversed}
cannam@127: when they are passed to the FFTW plan creation, thanks to differences
cannam@127: in array indexing conventions (@pxref{Multi-dimensional Array
cannam@127: Format}).  This is @emph{unlike} the legacy Fortran interface
cannam@127: (@pxref{Fortran-interface routines}), which reversed the dimensions
cannam@127: for you.  @xref{Reversing array dimensions}.
cannam@127: 
cannam@127: @item
cannam@127: @cindex alignment
cannam@127: @cindex SIMD
cannam@127: Using ordinary Fortran array declarations like this works, but may
cannam@127: yield suboptimal performance because the data may not be not aligned
cannam@127: to exploit SIMD instructions on modern proessors (@pxref{SIMD
cannam@127: alignment and fftw_malloc}). Better performance will often be obtained
cannam@127: by allocating with @samp{fftw_alloc}. @xref{Allocating aligned memory
cannam@127: in Fortran}.
cannam@127: 
cannam@127: @item
cannam@127: @findex fftw_execute
cannam@127: Similar to the legacy Fortran interface (@pxref{FFTW Execution in
cannam@127: Fortran}), we currently recommend @emph{not} using @code{fftw_execute}
cannam@127: but rather using the more specialized functions like
cannam@127: @code{fftw_execute_dft} (@pxref{New-array Execute Functions}).  
cannam@127: However, you should execute the plan on the @code{same arrays} as the
cannam@127: ones for which you created the plan, unless you are especially
cannam@127: careful.  @xref{Plan execution in Fortran}.  To prevent
cannam@127: you from using @code{fftw_execute} by mistake, the @code{fftw3.f03}
cannam@127: file does not provide an @code{fftw_execute} interface declaration.
cannam@127: 
cannam@127: @item
cannam@127: @cindex flags
cannam@127: Multiple planner flags are combined with @code{ior} (equivalent to @samp{|} in C).  e.g. @code{FFTW_MEASURE | FFTW_DESTROY_INPUT} becomes @code{ior(FFTW_MEASURE, FFTW_DESTROY_INPUT)}.  (You can also use @samp{+} as long as you don't try to include a given flag more than once.)
cannam@127: 
cannam@127: @end itemize
cannam@127: 
cannam@127: @menu
cannam@127: * Extended and quadruple precision in Fortran::
cannam@127: @end menu
cannam@127: 
cannam@127: @node Extended and quadruple precision in Fortran,  , Overview of Fortran interface, Overview of Fortran interface
cannam@127: @subsection Extended and quadruple precision in Fortran
cannam@127: @cindex precision
cannam@127: 
cannam@127: If FFTW is compiled in @code{long double} (extended) precision
cannam@127: (@pxref{Installation and Customization}), you may be able to call the
cannam@127: resulting @code{fftwl_} routines (@pxref{Precision}) from Fortran if
cannam@127: your compiler supports the @code{C_LONG_DOUBLE_COMPLEX} type code.
cannam@127: 
cannam@127: Because some Fortran compilers do not support
cannam@127: @code{C_LONG_DOUBLE_COMPLEX}, the @code{fftwl_} declarations are
cannam@127: segregated into a separate interface file @code{fftw3l.f03}, which you
cannam@127: should include @emph{in addition} to @code{fftw3.f03} (which declares
cannam@127: precision-independent @samp{FFTW_} constants):
cannam@127: 
cannam@127: @cindex iso_c_binding
cannam@127: @example
cannam@127:   use, intrinsic :: iso_c_binding 
cannam@127:   include 'fftw3.f03'
cannam@127:   include 'fftw3l.f03'
cannam@127: @end example
cannam@127: 
cannam@127: We also support using the nonstandard @code{__float128}
cannam@127: quadruple-precision type provided by recent versions of @code{gcc} on
cannam@127: 32- and 64-bit x86 hardware (@pxref{Installation and Customization}),
cannam@127: using the corresponding @code{real(16)} and @code{complex(16)} types
cannam@127: supported by @code{gfortran}.  The quadruple-precision @samp{fftwq_}
cannam@127: functions (@pxref{Precision}) are declared in a @code{fftw3q.f03}
cannam@127: interface file, which should be included in addition to
cannam@127: @code{fftw3l.f03}, as above.  You should also link with
cannam@127: @code{-lfftw3q -lquadmath -lm} as in C.
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node Reversing array dimensions, FFTW Fortran type reference, Overview of Fortran interface, Calling FFTW from Modern Fortran
cannam@127: @section Reversing array dimensions
cannam@127: 
cannam@127: @cindex row-major
cannam@127: @cindex column-major
cannam@127: A minor annoyance in calling FFTW from Fortran is that FFTW's array
cannam@127: dimensions are defined in the C convention (row-major order), while
cannam@127: Fortran's array dimensions are the opposite convention (column-major
cannam@127: order). @xref{Multi-dimensional Array Format}.  This is just a
cannam@127: bookkeeping difference, with no effect on performance.  The only
cannam@127: consequence of this is that, whenever you create an FFTW plan for a
cannam@127: multi-dimensional transform, you must always @emph{reverse the
cannam@127: ordering of the dimensions}.
cannam@127: 
cannam@127: For example, consider the three-dimensional (@threedims{L,M,N}) arrays:
cannam@127: 
cannam@127: @example
cannam@127:   complex(C_DOUBLE_COMPLEX), dimension(L,M,N) :: in, out
cannam@127: @end example
cannam@127: 
cannam@127: To plan a DFT for these arrays using @code{fftw_plan_dft_3d}, you could do:
cannam@127: 
cannam@127: @findex fftw_plan_dft_3d
cannam@127: @example
cannam@127:   plan = fftw_plan_dft_3d(N,M,L, in,out, FFTW_FORWARD,FFTW_ESTIMATE)
cannam@127: @end example
cannam@127: 
cannam@127: That is, from FFTW's perspective this is a @threedims{N,M,L} array.
cannam@127: @emph{No data transposition need occur}, as this is @emph{only
cannam@127: notation}.  Similarly, to use the more generic routine
cannam@127: @code{fftw_plan_dft} with the same arrays, you could do:
cannam@127: 
cannam@127: @example
cannam@127:   integer(C_INT), dimension(3) :: n = [N,M,L]
cannam@127:   plan = fftw_plan_dft_3d(3, n, in,out, FFTW_FORWARD,FFTW_ESTIMATE)
cannam@127: @end example
cannam@127: 
cannam@127: Note, by the way, that this is different from the legacy Fortran
cannam@127: interface (@pxref{Fortran-interface routines}), which automatically
cannam@127: reverses the order of the array dimension for you.  Here, you are
cannam@127: calling the C interface directly, so there is no ``translation'' layer.
cannam@127: 
cannam@127: @cindex r2c/c2r multi-dimensional array format
cannam@127: An important thing to keep in mind is the implication of this for
cannam@127: multidimensional real-to-complex transforms (@pxref{Multi-Dimensional
cannam@127: DFTs of Real Data}).  In C, a multidimensional real-to-complex DFT
cannam@127: chops the last dimension roughly in half (@threedims{N,M,L} real input
cannam@127: goes to @threedims{N,M,L/2+1} complex output).  In Fortran, because
cannam@127: the array dimension notation is reversed, the @emph{first} dimension of
cannam@127: the complex data is chopped roughly in half.  For example consider the
cannam@127: @samp{r2c} transform of @threedims{L,M,N} real input in Fortran:
cannam@127: 
cannam@127: @findex fftw_plan_dft_r2c_3d
cannam@127: @findex fftw_execute_dft_r2c
cannam@127: @example
cannam@127:   type(C_PTR) :: plan
cannam@127:   real(C_DOUBLE), dimension(L,M,N) :: in
cannam@127:   complex(C_DOUBLE_COMPLEX), dimension(L/2+1,M,N) :: out
cannam@127:   plan = fftw_plan_dft_r2c_3d(N,M,L, in,out, FFTW_ESTIMATE)
cannam@127:   ...
cannam@127:   call fftw_execute_dft_r2c(plan, in, out)
cannam@127: @end example
cannam@127: 
cannam@127: @cindex in-place
cannam@127: @cindex padding
cannam@127: Alternatively, for an in-place r2c transform, as described in the C
cannam@127: documentation we must @emph{pad} the @emph{first} dimension of the
cannam@127: real input with an extra two entries (which are ignored by FFTW) so as
cannam@127: to leave enough space for the complex output. The input is
cannam@127: @emph{allocated} as a @threedims{2[L/2+1],M,N} array, even though only
cannam@127: @threedims{L,M,N} of it is actually used.  In this example, we will
cannam@127: allocate the array as a pointer type, using @samp{fftw_alloc} to
cannam@127: ensure aligned memory for maximum performance (@pxref{Allocating
cannam@127: aligned memory in Fortran}); this also makes it easy to reference the
cannam@127: same memory as both a real array and a complex array.
cannam@127: 
cannam@127: @findex fftw_alloc_complex
cannam@127: @findex c_f_pointer
cannam@127: @example
cannam@127:   real(C_DOUBLE), pointer :: in(:,:,:)
cannam@127:   complex(C_DOUBLE_COMPLEX), pointer :: out(:,:,:)
cannam@127:   type(C_PTR) :: plan, data
cannam@127:   data = fftw_alloc_complex(int((L/2+1) * M * N, C_SIZE_T))
cannam@127:   call c_f_pointer(data, in, [2*(L/2+1),M,N])
cannam@127:   call c_f_pointer(data, out, [L/2+1,M,N])
cannam@127:   plan = fftw_plan_dft_r2c_3d(N,M,L, in,out, FFTW_ESTIMATE)
cannam@127:   ...
cannam@127:   call fftw_execute_dft_r2c(plan, in, out)
cannam@127:   ...
cannam@127:   call fftw_destroy_plan(plan)
cannam@127:   call fftw_free(data)
cannam@127: @end example
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node FFTW Fortran type reference, Plan execution in Fortran, Reversing array dimensions, Calling FFTW from Modern Fortran
cannam@127: @section FFTW Fortran type reference
cannam@127: 
cannam@127: The following are the most important type correspondences between the
cannam@127: C interface and Fortran:
cannam@127: 
cannam@127: @itemize @bullet
cannam@127: 
cannam@127: @item
cannam@127: @tindex fftw_plan
cannam@127: Plans (@code{fftw_plan} and variants) are @code{type(C_PTR)} (i.e. an
cannam@127: opaque pointer).
cannam@127: 
cannam@127: @item
cannam@127: @tindex fftw_complex
cannam@127: @cindex precision
cannam@127: @ctindex C_DOUBLE
cannam@127: @ctindex C_FLOAT
cannam@127: @ctindex C_LONG_DOUBLE
cannam@127: @ctindex C_DOUBLE_COMPLEX
cannam@127: @ctindex C_FLOAT_COMPLEX
cannam@127: @ctindex C_LONG_DOUBLE_COMPLEX
cannam@127: The C floating-point types @code{double}, @code{float}, and @code{long
cannam@127: double} correspond to @code{real(C_DOUBLE)}, @code{real(C_FLOAT)}, and
cannam@127: @code{real(C_LONG_DOUBLE)}, respectively.  The C complex types
cannam@127: @code{fftw_complex}, @code{fftwf_complex}, and @code{fftwl_complex}
cannam@127: correspond in Fortran to @code{complex(C_DOUBLE_COMPLEX)},
cannam@127: @code{complex(C_FLOAT_COMPLEX)}, and
cannam@127: @code{complex(C_LONG_DOUBLE_COMPLEX)}, respectively.  
cannam@127: Just as in C
cannam@127: (@pxref{Precision}), the FFTW subroutines and types are prefixed with
cannam@127: @samp{fftw_}, @code{fftwf_}, and @code{fftwl_} for the different precisions, and link to different libraries (@code{-lfftw3}, @code{-lfftw3f}, and @code{-lfftw3l} on Unix), but use the @emph{same} include file @code{fftw3.f03} and the @emph{same} constants (all of which begin with @samp{FFTW_}).  The exception is @code{long double} precision, for which you should @emph{also} include @code{fftw3l.f03} (@pxref{Extended and quadruple precision in Fortran}).
cannam@127: 
cannam@127: @item
cannam@127: @tindex ptrdiff_t
cannam@127: @ctindex C_INT
cannam@127: @ctindex C_INTPTR_T
cannam@127: @ctindex C_SIZE_T
cannam@127: @findex fftw_malloc
cannam@127: The C integer types @code{int} and @code{unsigned} (used for planner
cannam@127: flags) become @code{integer(C_INT)}.  The C integer type @code{ptrdiff_t} (e.g. in the @ref{64-bit Guru Interface}) becomes @code{integer(C_INTPTR_T)}, and @code{size_t} (in @code{fftw_malloc} etc.) becomes @code{integer(C_SIZE_T)}.
cannam@127: 
cannam@127: @item
cannam@127: @tindex fftw_r2r_kind
cannam@127: @ctindex C_FFTW_R2R_KIND
cannam@127: The @code{fftw_r2r_kind} type (@pxref{Real-to-Real Transform Kinds})
cannam@127: becomes @code{integer(C_FFTW_R2R_KIND)}.  The various constant values
cannam@127: of the C enumerated type (@code{FFTW_R2HC} etc.) become simply integer
cannam@127: constants of the same names in Fortran.
cannam@127: 
cannam@127: @item
cannam@127: @ctindex FFTW_DESTROY_INPUT
cannam@127: @cindex in-place
cannam@127: @findex fftw_flops
cannam@127: Numeric array pointer arguments (e.g. @code{double *})
cannam@127: become @code{dimension(*), intent(out)} arrays of the same type, or
cannam@127: @code{dimension(*), intent(in)} if they are pointers to constant data
cannam@127: (e.g. @code{const int *}).  There are a few exceptions where numeric
cannam@127: pointers refer to scalar outputs (e.g. for @code{fftw_flops}), in which
cannam@127: case they are @code{intent(out)} scalar arguments in Fortran too.
cannam@127: For the new-array execute functions (@pxref{New-array Execute Functions}),
cannam@127: the input arrays are declared @code{dimension(*), intent(inout)}, since
cannam@127: they can be modified in the case of in-place or @code{FFTW_DESTROY_INPUT}
cannam@127: transforms.
cannam@127: 
cannam@127: @item
cannam@127: @findex fftw_alloc_real
cannam@127: @findex c_f_pointer
cannam@127: Pointer @emph{return} values (e.g @code{double *}) become
cannam@127: @code{type(C_PTR)}.  (If they are pointers to arrays, as for
cannam@127: @code{fftw_alloc_real}, you can convert them back to Fortran array
cannam@127: pointers with the standard intrinsic function @code{c_f_pointer}.)
cannam@127: 
cannam@127: @item
cannam@127: @cindex guru interface
cannam@127: @tindex fftw_iodim
cannam@127: @tindex fftw_iodim64
cannam@127: @cindex 64-bit architecture
cannam@127: The @code{fftw_iodim} type in the guru interface (@pxref{Guru vector
cannam@127: and transform sizes}) becomes @code{type(fftw_iodim)} in Fortran, a
cannam@127: derived data type (the Fortran analogue of C's @code{struct}) with
cannam@127: three @code{integer(C_INT)} components: @code{n}, @code{is}, and
cannam@127: @code{os}, with the same meanings as in C.  The @code{fftw_iodim64} type in the 64-bit guru interface (@pxref{64-bit Guru Interface}) is the same, except that its components are of type @code{integer(C_INTPTR_T)}.
cannam@127: 
cannam@127: @item
cannam@127: @ctindex C_FUNPTR
cannam@127: Using the wisdom import/export functions from Fortran is a bit tricky,
cannam@127: and is discussed in @ref{Accessing the wisdom API from Fortran}.  In
cannam@127: brief, the @code{FILE *} arguments map to @code{type(C_PTR)}, @code{const char *} to @code{character(C_CHAR), dimension(*), intent(in)} (null-terminated!), and the generic read-char/write-char functions map to @code{type(C_FUNPTR)}.
cannam@127: 
cannam@127: @end itemize
cannam@127: 
cannam@127: @cindex portability
cannam@127: You may be wondering if you need to search-and-replace
cannam@127: @code{real(kind(0.0d0))} (or whatever your favorite Fortran spelling
cannam@127: of ``double precision'' is) with @code{real(C_DOUBLE)} everywhere in
cannam@127: your program, and similarly for @code{complex} and @code{integer}
cannam@127: types.  The answer is no; you can still use your existing types.  As
cannam@127: long as these types match their C counterparts, things should work
cannam@127: without a hitch.  The worst that can happen, e.g. in the (unlikely)
cannam@127: event of a system where @code{real(kind(0.0d0))} is different from
cannam@127: @code{real(C_DOUBLE)}, is that the compiler will give you a
cannam@127: type-mismatch error.  That is, if you don't use the
cannam@127: @code{iso_c_binding} kinds you need to accept at least the theoretical
cannam@127: possibility of having to change your code in response to compiler
cannam@127: errors on some future machine, but you don't need to worry about
cannam@127: silently compiling incorrect code that yields runtime errors.
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node Plan execution in Fortran, Allocating aligned memory in Fortran, FFTW Fortran type reference, Calling FFTW from Modern Fortran
cannam@127: @section Plan execution in Fortran
cannam@127: 
cannam@127: In C, in order to use a plan, one normally calls @code{fftw_execute},
cannam@127: which executes the plan to perform the transform on the input/output
cannam@127: arrays passed when the plan was created (@pxref{Using Plans}).  The
cannam@127: corresponding subroutine call in modern Fortran is:
cannam@127: @example
cannam@127:  call fftw_execute(plan)
cannam@127: @end example
cannam@127: @findex fftw_execute
cannam@127: 
cannam@127: However, we have had reports that this causes problems with some
cannam@127: recent optimizing Fortran compilers.  The problem is, because the
cannam@127: input/output arrays are not passed as explicit arguments to
cannam@127: @code{fftw_execute}, the semantics of Fortran (unlike C) allow the
cannam@127: compiler to assume that the input/output arrays are not changed by
cannam@127: @code{fftw_execute}.  As a consequence, certain compilers end up
cannam@127: repositioning the call to @code{fftw_execute}, assuming incorrectly
cannam@127: that it does nothing to the arrays.
cannam@127: 
cannam@127: There are various workarounds to this, but the safest and simplest
cannam@127: thing is to not use @code{fftw_execute} in Fortran.  Instead, use the
cannam@127: functions described in @ref{New-array Execute Functions}, which take
cannam@127: the input/output arrays as explicit arguments.  For example, if the
cannam@127: plan is for a complex-data DFT and was created for the arrays
cannam@127: @code{in} and @code{out}, you would do:
cannam@127: @example
cannam@127:  call fftw_execute_dft(plan, in, out)
cannam@127: @end example
cannam@127: @findex fftw_execute_dft
cannam@127: 
cannam@127: There are a few things to be careful of, however:
cannam@127: 
cannam@127: @itemize @bullet
cannam@127: 
cannam@127: @item
cannam@127: @findex fftw_execute_dft_r2c
cannam@127: @findex fftw_execute_dft_c2r
cannam@127: @findex fftw_execute_r2r
cannam@127: You must use the correct type of execute function, matching the way
cannam@127: the plan was created.  Complex DFT plans should use
cannam@127: @code{fftw_execute_dft}, Real-input (r2c) DFT plans should use use
cannam@127: @code{fftw_execute_dft_r2c}, and real-output (c2r) DFT plans should
cannam@127: use @code{fftw_execute_dft_c2r}.  The various r2r plans should use
cannam@127: @code{fftw_execute_r2r}.  Fortunately, if you use the wrong one you
cannam@127: will get a compile-time type-mismatch error (unlike legacy Fortran).
cannam@127: 
cannam@127: @item
cannam@127: You should normally pass the same input/output arrays that were used when
cannam@127: creating the plan.  This is always safe.
cannam@127: 
cannam@127: @item
cannam@127: @emph{If} you pass @emph{different} input/output arrays compared to
cannam@127: those used when creating the plan, you must abide by all the
cannam@127: restrictions of the new-array execute functions (@pxref{New-array
cannam@127: Execute Functions}).  The most tricky of these is the
cannam@127: requirement that the new arrays have the same alignment as the
cannam@127: original arrays; the best (and possibly only) way to guarantee this
cannam@127: is to use the @samp{fftw_alloc} functions to allocate your arrays (@pxref{Allocating aligned memory in Fortran}). Alternatively, you can
cannam@127: use the @code{FFTW_UNALIGNED} flag when creating the
cannam@127: plan, in which case the plan does not depend on the alignment, but
cannam@127: this may sacrifice substantial performance on architectures (like x86)
cannam@127: with SIMD instructions (@pxref{SIMD alignment and fftw_malloc}).
cannam@127: @ctindex FFTW_UNALIGNED
cannam@127: 
cannam@127: @end itemize
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node Allocating aligned memory in Fortran, Accessing the wisdom API from Fortran, Plan execution in Fortran, Calling FFTW from Modern Fortran
cannam@127: @section Allocating aligned memory in Fortran
cannam@127: 
cannam@127: @cindex alignment
cannam@127: @findex fftw_alloc_real
cannam@127: @findex fftw_alloc_complex
cannam@127: In order to obtain maximum performance in FFTW, you should store your
cannam@127: data in arrays that have been specially aligned in memory (@pxref{SIMD
cannam@127: alignment and fftw_malloc}).  Enforcing alignment also permits you to
cannam@127: safely use the new-array execute functions (@pxref{New-array Execute
cannam@127: Functions}) to apply a given plan to more than one pair of in/out
cannam@127: arrays.  Unfortunately, standard Fortran arrays do @emph{not} provide
cannam@127: any alignment guarantees.  The @emph{only} way to allocate aligned
cannam@127: memory in standard Fortran is to allocate it with an external C
cannam@127: function, like the @code{fftw_alloc_real} and
cannam@127: @code{fftw_alloc_complex} functions.  Fortunately, Fortran 2003 provides
cannam@127: a simple way to associate such allocated memory with a standard Fortran
cannam@127: array pointer that you can then use normally.
cannam@127: 
cannam@127: We therefore recommend allocating all your input/output arrays using
cannam@127: the following technique:
cannam@127: 
cannam@127: @enumerate
cannam@127: 
cannam@127: @item
cannam@127: Declare a @code{pointer}, @code{arr}, to your array of the desired type
cannam@127: and dimensions.  For example, @code{real(C_DOUBLE), pointer :: a(:,:)}
cannam@127: for a 2d real array, or @code{complex(C_DOUBLE_COMPLEX), pointer ::
cannam@127: a(:,:,:)} for a 3d complex array.
cannam@127: 
cannam@127: @item
cannam@127: The number of elements to allocate must be an
cannam@127: @code{integer(C_SIZE_T)}.  You can either declare a variable of this
cannam@127: type, e.g. @code{integer(C_SIZE_T) :: sz}, to store the number of
cannam@127: elements to allocate, or you can use the @code{int(..., C_SIZE_T)}
cannam@127: intrinsic function. e.g. set @code{sz = L * M * N} or use
cannam@127: @code{int(L * M * N, C_SIZE_T)} for an @threedims{L,M,N} array.
cannam@127: 
cannam@127: @item
cannam@127: Declare a @code{type(C_PTR) :: p} to hold the return value from
cannam@127: FFTW's allocation routine.  Set @code{p = fftw_alloc_real(sz)} for a real array, or @code{p = fftw_alloc_complex(sz)} for a complex array.
cannam@127: 
cannam@127: @item
cannam@127: @findex c_f_pointer
cannam@127: Associate your pointer @code{arr} with the allocated memory @code{p}
cannam@127: using the standard @code{c_f_pointer} subroutine: @code{call
cannam@127: c_f_pointer(p, arr, [...dimensions...])}, where
cannam@127: @code{[...dimensions...])} are an array of the dimensions of the array
cannam@127: (in the usual Fortran order). e.g. @code{call c_f_pointer(p, arr,
cannam@127: [L,M,N])} for an @threedims{L,M,N} array.  (Alternatively, you can
cannam@127: omit the dimensions argument if you specified the shape explicitly
cannam@127: when declaring @code{arr}.)  You can now use @code{arr} as a usual
cannam@127: multidimensional array.
cannam@127: 
cannam@127: @item
cannam@127: When you are done using the array, deallocate the memory by @code{call
cannam@127: fftw_free(p)} on @code{p}.
cannam@127: 
cannam@127: @end enumerate
cannam@127: 
cannam@127: For example, here is how we would allocate an @twodims{L,M} 2d real array:
cannam@127: 
cannam@127: @example
cannam@127:   real(C_DOUBLE), pointer :: arr(:,:)
cannam@127:   type(C_PTR) :: p
cannam@127:   p = fftw_alloc_real(int(L * M, C_SIZE_T))
cannam@127:   call c_f_pointer(p, arr, [L,M])
cannam@127:   @emph{...use arr and arr(i,j) as usual...}
cannam@127:   call fftw_free(p)
cannam@127: @end example
cannam@127: 
cannam@127: and here is an @threedims{L,M,N} 3d complex array:
cannam@127: 
cannam@127: @example
cannam@127:   complex(C_DOUBLE_COMPLEX), pointer :: arr(:,:,:)
cannam@127:   type(C_PTR) :: p
cannam@127:   p = fftw_alloc_complex(int(L * M * N, C_SIZE_T))
cannam@127:   call c_f_pointer(p, arr, [L,M,N])
cannam@127:   @emph{...use arr and arr(i,j,k) as usual...}
cannam@127:   call fftw_free(p)
cannam@127: @end example
cannam@127: 
cannam@127: See @ref{Reversing array dimensions} for an example allocating a
cannam@127: single array and associating both real and complex array pointers with
cannam@127: it, for in-place real-to-complex transforms.
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node Accessing the wisdom API from Fortran, Defining an FFTW module, Allocating aligned memory in Fortran, Calling FFTW from Modern Fortran
cannam@127: @section Accessing the wisdom API from Fortran
cannam@127: @cindex wisdom
cannam@127: @cindex saving plans to disk
cannam@127: 
cannam@127: As explained in @ref{Words of Wisdom-Saving Plans}, FFTW provides a
cannam@127: ``wisdom'' API for saving plans to disk so that they can be recreated
cannam@127: quickly.  The C API for exporting (@pxref{Wisdom Export}) and
cannam@127: importing (@pxref{Wisdom Import}) wisdom is somewhat tricky to use
cannam@127: from Fortran, however, because of differences in file I/O and string
cannam@127: types between C and Fortran.
cannam@127: 
cannam@127: @menu
cannam@127: * Wisdom File Export/Import from Fortran::
cannam@127: * Wisdom String Export/Import from Fortran::
cannam@127: * Wisdom Generic Export/Import from Fortran::
cannam@127: @end menu
cannam@127: 
cannam@127: @c =========>
cannam@127: @node Wisdom File Export/Import from Fortran, Wisdom String Export/Import from Fortran, Accessing the wisdom API from Fortran, Accessing the wisdom API from Fortran
cannam@127: @subsection Wisdom File Export/Import from Fortran
cannam@127: 
cannam@127: @findex fftw_import wisdom_from_filename
cannam@127: @findex fftw_export_wisdom_to_filename
cannam@127: The easiest way to export and import wisdom is to do so using
cannam@127: @code{fftw_export_wisdom_to_filename} and
cannam@127: @code{fftw_wisdom_from_filename}.  The only trick is that these
cannam@127: require you to pass a C string, which is an array of type
cannam@127: @code{CHARACTER(C_CHAR)} that is terminated by @code{C_NULL_CHAR}.
cannam@127: You can call them like this:
cannam@127: 
cannam@127: @example
cannam@127:   integer(C_INT) :: ret
cannam@127:   ret = fftw_export_wisdom_to_filename(C_CHAR_'my_wisdom.dat' // C_NULL_CHAR)
cannam@127:   if (ret .eq. 0) stop 'error exporting wisdom to file'
cannam@127:   ret = fftw_import_wisdom_from_filename(C_CHAR_'my_wisdom.dat' // C_NULL_CHAR)
cannam@127:   if (ret .eq. 0) stop 'error importing wisdom from file'
cannam@127: @end example
cannam@127: 
cannam@127: Note that prepending @samp{C_CHAR_} is needed to specify that the
cannam@127: literal string is of kind @code{C_CHAR}, and we null-terminate the
cannam@127: string by appending @samp{// C_NULL_CHAR}.  These functions return an
cannam@127: @code{integer(C_INT)} (@code{ret}) which is @code{0} if an error
cannam@127: occurred during export/import and nonzero otherwise.
cannam@127: 
cannam@127: It is also possible to use the lower-level routines
cannam@127: @code{fftw_export_wisdom_to_file} and
cannam@127: @code{fftw_import_wisdom_from_file}, which accept parameters of the C
cannam@127: type @code{FILE*}, expressed in Fortran as @code{type(C_PTR)}.
cannam@127: However, you are then responsible for creating the @code{FILE*}
cannam@127: yourself.  You can do this by using @code{iso_c_binding} to define
cannam@127: Fortran intefaces for the C library functions @code{fopen} and
cannam@127: @code{fclose}, which is a bit strange in Fortran but workable.
cannam@127: 
cannam@127: @c =========>
cannam@127: @node Wisdom String Export/Import from Fortran, Wisdom Generic Export/Import from Fortran, Wisdom File Export/Import from Fortran, Accessing the wisdom API from Fortran
cannam@127: @subsection Wisdom String Export/Import from Fortran
cannam@127: 
cannam@127: @findex fftw_export_wisdom_to_string
cannam@127: Dealing with FFTW's C string export/import is a bit more painful.  In
cannam@127: particular, the @code{fftw_export_wisdom_to_string} function requires
cannam@127: you to deal with a dynamically allocated C string.  To get its length,
cannam@127: you must define an interface to the C @code{strlen} function, and to
cannam@127: deallocate it you must define an interface to C @code{free}:
cannam@127: 
cannam@127: @example
cannam@127:   use, intrinsic :: iso_c_binding
cannam@127:   interface
cannam@127:     integer(C_INT) function strlen(s) bind(C, name='strlen')
cannam@127:       import
cannam@127:       type(C_PTR), value :: s
cannam@127:     end function strlen
cannam@127:     subroutine free(p) bind(C, name='free')
cannam@127:       import
cannam@127:       type(C_PTR), value :: p
cannam@127:     end subroutine free
cannam@127:   end interface
cannam@127: @end example
cannam@127: 
cannam@127: Given these definitions, you can then export wisdom to a Fortran
cannam@127: character array:
cannam@127: 
cannam@127: @example
cannam@127:   character(C_CHAR), pointer :: s(:)
cannam@127:   integer(C_SIZE_T) :: slen
cannam@127:   type(C_PTR) :: p
cannam@127:   p = fftw_export_wisdom_to_string()
cannam@127:   if (.not. c_associated(p)) stop 'error exporting wisdom'
cannam@127:   slen = strlen(p)
cannam@127:   call c_f_pointer(p, s, [slen+1])
cannam@127:   ...
cannam@127:   call free(p)
cannam@127: @end example
cannam@127: @findex c_associated
cannam@127: @findex c_f_pointer
cannam@127: 
cannam@127: Note that @code{slen} is the length of the C string, but the length of
cannam@127: the array is @code{slen+1} because it includes the terminating null
cannam@127: character.  (You can omit the @samp{+1} if you don't want Fortran to
cannam@127: know about the null character.) The standard @code{c_associated} function
cannam@127: checks whether @code{p} is a null pointer, which is returned by
cannam@127: @code{fftw_export_wisdom_to_string} if there was an error.
cannam@127: 
cannam@127: @findex fftw_import_wisdom_from_string
cannam@127: To import wisdom from a string, use
cannam@127: @code{fftw_import_wisdom_from_string} as usual; note that the argument
cannam@127: of this function must be a @code{character(C_CHAR)} that is terminated
cannam@127: by the @code{C_NULL_CHAR} character, like the @code{s} array above.
cannam@127: 
cannam@127: @c =========>
cannam@127: @node Wisdom Generic Export/Import from Fortran,  , Wisdom String Export/Import from Fortran, Accessing the wisdom API from Fortran
cannam@127: @subsection Wisdom Generic Export/Import from Fortran
cannam@127: 
cannam@127: The most generic wisdom export/import functions allow you to provide
cannam@127: an arbitrary callback function to read/write one character at a time
cannam@127: in any way you want.  However, your callback function must be written
cannam@127: in a special way, using the @code{bind(C)} attribute to be passed to a
cannam@127: C interface.
cannam@127: 
cannam@127: @findex fftw_export_wisdom
cannam@127: In particular, to call the generic wisdom export function
cannam@127: @code{fftw_export_wisdom}, you would write a callback subroutine of the form:
cannam@127: 
cannam@127: @example
cannam@127:   subroutine my_write_char(c, p) bind(C)
cannam@127:     use, intrinsic :: iso_c_binding
cannam@127:     character(C_CHAR), value :: c
cannam@127:     type(C_PTR), value :: p
cannam@127:     @emph{...write c...}
cannam@127:   end subroutine my_write_char
cannam@127: @end example
cannam@127: 
cannam@127: Given such a subroutine (along with the corresponding interface definition), you could then export wisdom using:
cannam@127: 
cannam@127: @findex c_funloc
cannam@127: @example
cannam@127:   call fftw_export_wisdom(c_funloc(my_write_char), p)
cannam@127: @end example
cannam@127: 
cannam@127: @findex c_loc
cannam@127: @findex c_f_pointer
cannam@127: The standard @code{c_funloc} intrinsic converts a Fortran
cannam@127: @code{bind(C)} subroutine into a C function pointer.  The parameter
cannam@127: @code{p} is a @code{type(C_PTR)} to any arbitrary data that you want
cannam@127: to pass to @code{my_write_char} (or @code{C_NULL_PTR} if none).  (Note
cannam@127: that you can get a C pointer to Fortran data using the intrinsic
cannam@127: @code{c_loc}, and convert it back to a Fortran pointer in
cannam@127: @code{my_write_char} using @code{c_f_pointer}.)
cannam@127: 
cannam@127: Similarly, to use the generic @code{fftw_import_wisdom}, you would
cannam@127: define a callback function of the form:
cannam@127: 
cannam@127: @findex fftw_import_wisdom
cannam@127: @example
cannam@127:   integer(C_INT) function my_read_char(p) bind(C)
cannam@127:     use, intrinsic :: iso_c_binding
cannam@127:     type(C_PTR), value :: p
cannam@127:     character :: c
cannam@127:     @emph{...read a character c...}
cannam@127:     my_read_char = ichar(c, C_INT)
cannam@127:   end function my_read_char
cannam@127: 
cannam@127:   ....
cannam@127: 
cannam@127:   integer(C_INT) :: ret
cannam@127:   ret = fftw_import_wisdom(c_funloc(my_read_char), p)
cannam@127:   if (ret .eq. 0) stop 'error importing wisdom'
cannam@127: @end example
cannam@127: 
cannam@127: Your function can return @code{-1} if the end of the input is reached.
cannam@127: Again, @code{p} is an arbitrary @code{type(C_PTR} that is passed
cannam@127: through to your function.  @code{fftw_import_wisdom} returns @code{0}
cannam@127: if an error occurred and nonzero otherwise.
cannam@127: 
cannam@127: @c -------------------------------------------------------
cannam@127: @node Defining an FFTW module,  , Accessing the wisdom API from Fortran, Calling FFTW from Modern Fortran
cannam@127: @section Defining an FFTW module
cannam@127: 
cannam@127: Rather than using the @code{include} statement to include the
cannam@127: @code{fftw3.f03} interface file in any subroutine where you want to
cannam@127: use FFTW, you might prefer to define an FFTW Fortran module.  FFTW
cannam@127: does not install itself as a module, primarily because
cannam@127: @code{fftw3.f03} can be shared between different Fortran compilers while
cannam@127: modules (in general) cannot.  However, it is trivial to define your
cannam@127: own FFTW module if you want.  Just create a file containing:
cannam@127: 
cannam@127: @example
cannam@127:   module FFTW3
cannam@127:     use, intrinsic :: iso_c_binding
cannam@127:     include 'fftw3.f03'
cannam@127:   end module
cannam@127: @end example
cannam@127: 
cannam@127: Compile this file into a module as usual for your compiler (e.g. with
cannam@127: @code{gfortran -c} you will get a file @code{fftw3.mod}).  Now,
cannam@127: instead of @code{include 'fftw3.f03'}, whenever you want to use FFTW
cannam@127: routines you can just do:
cannam@127: 
cannam@127: @example
cannam@127:   use FFTW3
cannam@127: @end example
cannam@127: 
cannam@127: as usual for Fortran modules.  (You still need to link to the FFTW
cannam@127: library, of course.)