# HG changeset patch # User paugier <pierre.augier@univ-grenoble-alpes.fr> # Date 1547483380 -3600 # Mon Jan 14 17:29:40 2019 +0100 # Node ID 1b06c95d411d7161fcb483c662b5dd2178a10e83 # Parent 8d42eee9da240d07d51ec5f57ae2c1eba76f4bc5 More modif diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -23,6 +23,8 @@ *.so +*/revision.tex + */*.pstats */.ipynb_checkpoints diff --git a/bib.bib b/bib.bib --- a/bib.bib +++ b/bib.bib @@ -6,7 +6,7 @@ title = "{FluidDyn}: a Python open-source framework for research and teaching in fluid dynamics", journal = "J. Open Research Software", - volume = "(to be submitted)", + volume = "(Submitted)", pages = "" } @@ -16,7 +16,7 @@ title = "{FluidFFT}: common {API} ({C}++ and {P}ython) for {F}ast {F}ourier {T}ransform libraries", journal = "J. Open Research Software", - volume = "(to be submitted)", + volume = "(Submitted)", pages = "" } @@ -26,7 +26,7 @@ title = "{FluidSim}: modular, object-oriented Python package for high-performance {CFD} simulations", journal = "J. Open Research Software", - volume = "(to be submitted)", + volume = "(Submitted)", pages = "" } @@ -384,7 +384,7 @@ pages = {201--239}, } - + @InProceedings{ramachandran_pysph_2016, author = { {P}rabhu {R}amachandran }, title = { {P}y{S}{P}{H}: a reproducible and high-performance framework for smoothed particle hydrodynamics }, diff --git a/fluiddyn_meta/Makefile b/fluiddyn_meta/Makefile --- a/fluiddyn_meta/Makefile +++ b/fluiddyn_meta/Makefile @@ -18,6 +18,9 @@ revision: revision.tex revision.pdf clean +rebuttal.pdf: rebuttal.md + pandoc $< -o $@ + clean: rm -f *.log *.aux *.out *.bbl *.blg *.tmp rm -rf _minted-$(name) diff --git a/fluiddyn_meta/fluiddyn_metapaper.tex b/fluiddyn_meta/fluiddyn_metapaper.tex --- a/fluiddyn_meta/fluiddyn_metapaper.tex +++ b/fluiddyn_meta/fluiddyn_metapaper.tex @@ -103,8 +103,9 @@ % Keywords should make it easy to identify who and what the software will be % useful for.} -Fluid dynamics research with Python. Free and open-source software, modular, -object-oriented, collaborative, efficient, tested, documented. +Fluid dynamics research with Python. Numerical simulations. Laboratory +experiments. Free and open-source software, modular, object-oriented, +collaborative, efficient, tested, documented. \section*{Introduction} @@ -222,6 +223,8 @@ scientists in the field and that we can build together a nice, user-friendly and efficient ecosystem specialized in research and teaching in fluid dynamics. + + \section*{Implementation and architecture} % \textcolor{blue}{How the software was implemented, with details of the @@ -247,6 +250,9 @@ (\url{https://fluiddyn.readthedocs.io}) and some prominent features are presented in the following subsection. +\item \pack{Transonic}: a pure Python package to accelerate Python-Numpy code +with Pythran and potentially other Python compilers. + \item \fluidpack{fft}~\cite[see the companion paper][]{fluidfft}: a package which provides C++ and Python classes unifying various libraries to perform Fast Fourier Transform (FFT) in sequential and in parallel. @@ -294,6 +300,8 @@ it has been made forward compatible with Python 3 through the use of external package \pack{future}. % +We now tend to abandon Python 2.7 support for the next releases of the package. +% This article will now focus on the base package \fluiddyn. \subsection*{API of the Python library \fluiddyn} @@ -424,6 +432,11 @@ by default the notebooks with a file name ending as `.nbconvert.ipynb' are excluded. +\item \codeinline{fluidcluster-help} + +Tiny utility to print a short documentation on the most useful commands to +interact with the scheduler of a HPC cluster. + \item \codeinline{fluidmat2py} Utility to produce a strange code which is no longer Matlab and not yet Python. @@ -475,7 +488,9 @@ % \textcolor{blue}{Please include minimum version compatibility.} -Python 2.7, 3.4 or above. +Python 2.7, 3.4 or above. For the next versions, we will +\href{https://python3statement.org/}{drop Python 2.7 support and Python $>=$ +3.6 will be required}. % \section*{Additional system requirements} diff --git a/fluiddyn_meta/rebuttal.md b/fluiddyn_meta/rebuttal.md new file mode 100644 --- /dev/null +++ b/fluiddyn_meta/rebuttal.md @@ -0,0 +1,27 @@ +--- +title: Rebuttal for comments on FluidDyn manuscript +--- + +# Editorial Revision Requests: + +# Minor revisions: + +## consider changing the title of the paper to make it more descriptive of the functionality of the package + +We changed the title of the paper which is now: + +"FluidDyn: a Python open-source framework for research and teaching in fluid +dynamics by simulations, experiments and data processing" + +## check and clarify installation instructions (note Reviewer A's comment about Python versions) + +The installation instructions are now much clearer. We have clearly stated that +we will drop Python 2.7 support for the next releases of the FluidDyn packages. + +## add link to documentation in the packages readme.rst file + +Done. + +## fix typos (see in particular Reviewer B's comments) + +Done. \ No newline at end of file diff --git a/fluidsim/Makefile b/fluidsim/Makefile --- a/fluidsim/Makefile +++ b/fluidsim/Makefile @@ -18,6 +18,9 @@ revision: revision.tex revision.pdf clean +rebuttal.pdf: rebuttal.md + pandoc $< -o $@ + clean: rm -f *.log *.aux *.out *.bbl *.blg *.tmp rm -rf _minted-* diff --git a/fluidsim/editor_decision/reviewerC.txt b/fluidsim/editor_decision/reviewerC.txt --- a/fluidsim/editor_decision/reviewerC.txt +++ b/fluidsim/editor_decision/reviewerC.txt @@ -38,7 +38,16 @@ No Comments (optional): - This section states that 60% of the codebase is covered by unit tests. However, no specific verification results are mentioned that test the accuracy of the solver as a whole. The authors should consider running a standard test-problem, such as the Taylor-Green Vortex problem described here, https://www.grc.nasa.gov/hiocfd/wp-content/uploads/sites/22/case_c3.3.pdf, which is the verification problem used in the SpectralDNS methods paper, or describe other verification tests they have performed. + + + This section states that 60% of the codebase is covered by unit tests. + However, no specific verification results are mentioned that test the + accuracy of the solver as a whole. The authors should consider running + a standard test-problem, such as the Taylor-Green Vortex problem + described here, + https://www.grc.nasa.gov/hiocfd/wp-content/uploads/sites/22/case_c3.3.pdf, + which is the verification problem used in the SpectralDNS methods + paper, or describe other verification tests they have performed. Does the Reuse section provide concrete and useful suggestions for reuse of the software, for instance: other potential applications, ways of extending or modifying the software, integration with other software?: Yes diff --git a/fluidsim/fluidsim_paper.tex b/fluidsim/fluidsim_paper.tex --- a/fluidsim/fluidsim_paper.tex +++ b/fluidsim/fluidsim_paper.tex @@ -1036,14 +1036,11 @@ detail, the issue of the scalability of pseudo-spectral codes based on Fourier transforms in the previous section and in the companion paper \citep{fluidfft}. -% In contrast to the framework \fluidpack{sim} for which it is easy to define a new solver for a new set of equations, NS3D is specialized in solving the Navier-Stokes equations under the Boussinesq approximation. Using NS3D to solve a new set of equations would require very deep changes in many places in the code. -% - Note that Dedalus does not implement the standard fully explicit RK4 method\footnote{See \href{https://bitbucket.org/dedalus-project/dedalus/issues/38/% @@ -1068,8 +1065,8 @@ \hline & \fluidpack{sim} & Dedalus & SpectralDNS & NS3D \\ \hline - 512$^2$ & 0.54 & 8.01 & 0.92 & 0.82 \\ - 1024$^2$ & 2.69 & 43.00 & 3.48 & 3.96 \\ + 512$^2$ & 0.51 & 1.53 & 0.92 & 0.82 \\ + 1024$^2$ & 2.61 & 8.00 & 3.48 & 3.96 \\ \hline \end{tabular} \caption{Elapsed times (in seconds) for ten RK4 time steps for two bidimensional @@ -1080,19 +1077,21 @@ We first compare the elapsed times for two resolutions (512$^2$ and 1024$^2$) over a bidimensional space. The results are summarized in Table~\ref{table:compare}. % -The results are consistent for the two resolutions. \fluidpack{sim} is the -fastest code for these cases. Dedalus is more than one order of magnitude slower -but as discussed earlier, the time stepping method is different. Also note -that Dedalus has been optimized for bounded domains with Chebyshev +The results are consistent for the two resolutions. \fluidpack{sim} is the +fastest code for these cases. Dedalus is three times slower than +\fluidpack{sim} but as discussed earlier, the time stepping method is +different. Another notable issue of Dedalus is a long initialization time (more +than 3 min for 1024$^2$ compared to approximately 5~s for \fluidpack{sim}). +Also note that Dedalus has been optimized for bounded domains with Chebyshev methods. % The two other codes SpectralDNS and NS3D have similar performance: slightly slower than \fluidpack{sim} and much faster than Dedalus. % -The Fortran code NS3D is evidently slower (by 47\%) than the Python code -\fluidpack{sim}. This can be explained by the fact that there is no specialized -numerical scheme for the 2D case in NS3D, so that more FFTs have to be performed -compared to SpectralDNS and \fluidpack{sim}. +The Fortran code NS3D is slower (by 47\%) than the Python code \fluidpack{sim}. +This can be explained by the fact that there is no specialized numerical scheme +for the 2D case in NS3D, so that more FFTs have to be performed compared to +SpectralDNS and \fluidpack{sim}. % This highlights the importance of implementing a well-adapted algorithm for a class of problems, which is much easier with a highly modular code as @@ -1198,6 +1197,10 @@ % For \fluidpack{sim}, the code coverage results are displayed at \href{https://codecov.io/bb/fluiddyn/fluidsim}{Codecov}. +% +\fluidpack{sim} has also been checked by comparing its results for wellknown +verification problems, as for example the Taylor-Green Vortices for the +incompressible Navier-Stokes equations. We also try to follow a consistent code style as recommended by PEP (Python enhancement proposals) 8 and 257. This is also inspected using lint @@ -1217,7 +1220,9 @@ \section*{Programming language} -Python 2.7, 3.4 or above. +Python 2.7, 3.4 or above. For the next versions, we will +\href{https://python3statement.org/}{drop Python 2.7 support and Python $>=$ +3.6 will be required}. \section*{Dependencies} diff --git a/fluidsim/rebuttal.md b/fluidsim/rebuttal.md new file mode 100644 --- /dev/null +++ b/fluidsim/rebuttal.md @@ -0,0 +1,53 @@ +--- +title: Rebuttal for comments on FluidSim manuscript +--- + +# Editorial Revision Requests: + +# Minor revisions: + +## add keywords to describe the numerical methodology and solver domains + +We changed the keywords as follow: + +"0D; 1D; 2D; 3D; pseudo-spectral; finite difference; computational fluid +dynamics; sequential; MPI; GPU" + +## describe the test problem used in the inter-code comparison in more detail (see reviewer C). + +We added a precise description of the test problem as discutted by reviewer C (see p. 16 of the new version of the manuscript). + +We have also updated the result of the code Dedalus with its new version. + +## respond to comment on comparison with serial performance, comparison between MPI vs GPU raised by Reviewer B + +We have included a comparison with serial performance. + +Unfortunately we have not been able to include comparison between MPI vs GPU. + +## correct typos / clarifications as indicated by Reviewer B + +Done. + +# Optional revisions (not required for acceptance): + +## consider adding a link to the online documentation in the readme.rst file + +Done. + +## consider using a more specific paper title indicating the pseudospectral methodology + +FluidSim is much more general than pseudospectral methods so it would be misleading to include this name in the title. + +## consider transforming plots of strong-scaling speedup "S" into the commonly-used "strong-scaling efficiency", which compensates for the expected/perfect speedup. + +We prefer to keep the figures as they are because they show the performance +improvement when the number of processes are increased. + +## consider representing the data in Figure 6 as a table. + +We think these data are better represented by a figure than by a table. + +## consider providing additional information as to why the FFTWMPI2D results cannot be run at higher processor counts. + +We included some words on this issue with a link towards a FluidFFT issue (#4).