# 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).