6.7.1 Basic distributed-transpose interface

In particular, suppose that we have an n0 by n1 array in row-major order, block-distributed across the n0 dimension. To transpose this into an n1 by n0 array block-distributed across the n1 dimension, we would create a plan by calling the following function:

     fftw_plan fftw_mpi_plan_transpose(ptrdiff_t n0, ptrdiff_t n1,
                                       double *in, double *out,
                                       MPI_Comm comm, unsigned flags);

The input and output arrays (in and out) can be the same. The transpose is actually executed by calling fftw_execute on the plan, as usual.

The flags are the usual FFTW planner flags, but support two additional flags: FFTW_MPI_TRANSPOSED_OUT and/or FFTW_MPI_TRANSPOSED_IN. What these flags indicate, for transpose plans, is that the output and/or input, respectively, are locally transposed. That is, on each process input data is normally stored as a local_n0 by n1 array in row-major order, but for an FFTW_MPI_TRANSPOSED_IN plan the input data is stored as n1 by local_n0 in row-major order. Similarly, FFTW_MPI_TRANSPOSED_OUT means that the output is n0 by local_n1 instead of local_n1 by n0.

To determine the local size of the array on each process before and after the transpose, as well as the amount of storage that must be allocated, one should call fftw_mpi_local_size_2d_transposed, just as for a 2d DFT as described in the previous section:

     ptrdiff_t fftw_mpi_local_size_2d_transposed
                     (ptrdiff_t n0, ptrdiff_t n1, MPI_Comm comm,
                      ptrdiff_t *local_n0, ptrdiff_t *local_0_start,
                      ptrdiff_t *local_n1, ptrdiff_t *local_1_start);

Again, the return value is the local storage to allocate, which in this case is the number of real (double) values rather than complex numbers as in the previous examples.