# HG changeset patch # User Ashwin Vishnu <avmo@kth.se> # Date 1547577119 -3600 # Tue Jan 15 19:31:59 2019 +0100 # Node ID 7393fc200f12b17029d892c0ff2849e860e3a08a # Parent 059086e7b6e71dbcb68f8c81ecf6705e29a5a106 Fluidfft: elaborate rebuttal diff --git a/fluidfft/fluidfft_paper.tex b/fluidfft/fluidfft_paper.tex --- a/fluidfft/fluidfft_paper.tex +++ b/fluidfft/fluidfft_paper.tex @@ -121,8 +121,8 @@ Some of the well-known libraries are written in C, C++ and Fortran. The classical \libpack{FFTW} library supports MPI using 1D decomposition and hybrid parallelism -using MPI and OpenMP. Other libraries, now implement the 2D decomposition: -\libpack{PFFT} \citep{pippig_pfft2013}, \libpack{P3DFFT} +using MPI and OpenMP. Other libraries, now implement the 2D decomposition for +FFT over 3D arrays: \libpack{PFFT} \citep{pippig_pfft2013}, \libpack{P3DFFT} \citep{pekurovsky2012p3dfft}, \libpack{2decomp\&FFT} and so on. These libraries rely on MPI for the communications between processes, are optimized for supercomputers and scales well to hundreds of thousands of cores. However, since @@ -460,7 +460,7 @@ methods. These classes are accompanied by unit test cases. \item \pack{Pythran} functions to speedup critical methods in the Python -operators classes. +operator classes. \end{itemize} @@ -559,9 +559,10 @@ the first index for the physical input array. This restriction is as a result of some \libpack{FFTW} library internals and design choices adopted in \fluidpack{fft}. This limits \codeinline{fftw1d} (our own MPI implementation -using MPI types and sequential 1d fft) to 192 cores and \codeinline{fftwmpi3d} -to 384 cores. The latter can utilize more cores since it is capable of working -with empty arrays, while sharing some of the computational load. +using MPI types and 1D transforms from FFTW) to 192 cores and +\codeinline{fftwmpi3d} to 384 cores. The latter can utilize more cores since it +is capable of working with empty arrays, while sharing some of the +computational load. % The fastest methods for relatively low and high number of processes are \codeinline{fftw1d} and diff --git a/fluidfft/rebuttal.md b/fluidfft/rebuttal.md --- a/fluidfft/rebuttal.md +++ b/fluidfft/rebuttal.md @@ -41,29 +41,35 @@ We have created an issue and added some lines in the manuscript: -"For the aforementioned reasons, we have preferred Pythran to compile optimized -`operator` functions that complement the FFT classes. Although with this we -obtain remarkable performance, there is still room for some improvement, in -terms of logical implementation and allocation of arrays. For example, -applications such as CFD simulations often deals with non-linear terms which -require dealiasing. The FFT classes of FluidFFT, currently allocates the same -number of modes in the spectral array so as to transform the physical array. -Thereafter, we apply dealiasing by setting zeros to wavenumbers which are -larger than, say, two-thirds of the maximum wavenumber. Instead, we could take -into account dealiasing in the FFT classes to save some memory and computation -time (See [FluidFFT issue -21](https://bitbucket.org/fluiddyn/fluidfft/issues/21/))." +> "For the aforementioned reasons, we have preferred Pythran to compile optimized +> `operator` functions that complement the FFT classes. Although with this we +> obtain remarkable performance, there is still room for some improvement, in +> terms of logical implementation and allocation of arrays. For example, +> applications such as CFD simulations often deals with non-linear terms which +> require dealiasing. The FFT classes of FluidFFT, currently allocates the same +> number of modes in the spectral array so as to transform the physical array. +> Thereafter, we apply dealiasing by setting zeros to wavenumbers which are +> larger than, say, two-thirds of the maximum wavenumber. Instead, we could take +> into account dealiasing in the FFT classes to save some memory and computation +> time (See [FluidFFT issue +> 21](https://bitbucket.org/fluiddyn/fluidfft/issues/21/))." ## address typos and clarifications suggested by Reviewer B -Done. +We have fixed all the typos pointed out by the reviewer. We have clarified +that choosing between slab and pencil decompositions are only possible for FFT +over 3D arrays. The usage 'method' has been replaced with 'FFT library'. Other +clarifications were made to the statements which were pointed out to be vague by +the reviewer. ## respond to Reviewer C's query about FFTW1D algorithm use We now write: -"This limits `fftw1d` (our own MPI implementation using MPI types and -sequential 1d fft) to 192 cores and `fftwmpi3d` to 384 cores." +> "This limits `fftw1d` (our own MPI implementation using MPI types and 1D +> transforms from FFTW) to 192 cores and `fftwmpi3d` to 384 cores". + +which should shed light on the underlying algorithm. ## clarify scaling limitations of the slab-parallelized algorithms @@ -79,7 +85,7 @@ ## respond to Reviewer B's query about dependency on FluidDyn It is now clear that the Python package fluiddyn is not a dependency for the -C++ API. +C++ API. The dependencies for the C++ and Python API are distinctly mentioned. ## respond to Reviewer B's query about cuFFT comparison @@ -87,3 +93,4 @@ We did not add the cuFFT comparison because the hardware used for the benchmarks is not compatible with this library. +