Metos3D: the Marine Ecosystem Toolkit for Optimization and Simulation in 3-D – Part 1: Simulation Package v0.3.2

Piwonski, Jaroslaw; Slawig, Thomas

doi:https://doi.org/10.5194/gmd-9-3729-2016

Articles | Volume 9, issue 10

https://doi.org/10.5194/gmd-9-3729-2016

© Author(s) 2016. This work is distributed under
the Creative Commons Attribution 3.0 License.

https://doi.org/10.5194/gmd-9-3729-2016

© Author(s) 2016. This work is distributed under
the Creative Commons Attribution 3.0 License.

Articles | Volume 9, issue 10

Development and technical paper

|

19 Oct 2016

Development and technical paper |

| 19 Oct 2016

Metos3D: the Marine Ecosystem Toolkit for Optimization and Simulation in 3-D – Part 1: Simulation Package v0.3.2

Jaroslaw Piwonski and Thomas Slawig

Download

Final revised paper (published on 19 Oct 2016)
Preprint (discussion started on 16 Jun 2015)

Interactive discussion

Status: closed

AC: Author comment | RC: Referee comment | SC: Short comment | EC: Editor comment

- Printer-friendly version

- Supplement

RC C1344: 'Review', Anonymous Referee #1, 13 Jul 2015
RC C1396: 'Comments on "Metos3D: a marine ecosystem toolkit for optimization and simulation in 3-D – Simulation Package v0.2"', Anonymous Referee #2, 15 Jul 2015
EC C1679: 'Referee comments', Andrew Yool, 12 Aug 2015
AC C2834: 'Final Response', Jaroslaw Piwonski, 09 Nov 2015

Peer-review completion

AR: Author's response | RR: Referee report | ED: Editor decision

AR by Jaroslaw Piwonski on behalf of the Authors (08 Feb 2016) Manuscript

ED: Referee Nomination & Report Request started (10 Mar 2016) by Andrew Yool

RR by Anonymous Referee #1 (04 Apr 2016)

Suggestions for revision or reasons for rejection

This is a review of the second version of the manuscript : “Metos3D: A Marine Ecosystem Toolkit for Optimization and Simulation in 3-D – Simulation Package v0.3.2” by Piwonski and Slawig.

The manuscript has certainly improved from the previous version, the objectives are now outlined and it clearly transpires the effort made by the authors to improve its structure and readability. However, in its present form this manuscript is not ready yet for publication in GMD until further moderate changes are made to the text to eliminate most of the residual confusion. As a general comment, I think the lack of coherence in the terminology used throughout the paper is the reason of the “fugacity” of the main message that I have perceived. In other words, I think that if the authors try to call things the same way throughout the text, after having clearly defined them (if possible) things would improve significantly.

Finally, I would like to call the attention of the authors to something that would have made this reviewer's task much easier at little cost. The font chosen for the document where the answers to the reviewer's comments are reported is an incredibly poor one. This, together with the plain editing of the text made reading such document nothing short of painful. Latex is great but sometimes a more popular text editor can do wonders when it comes to highlighting text, using bold font etc etc; all things usually appreciated for these types of documents. Below are some comments and suggestions:

Main points:

-Section 1, page 1, lines 64-66. Here three strategies used to accelerate the computation of steady-state are mentioned as they are put together in Metos3D. I was expecting later in the text to find somehow a tighter correspondence to this outline in the organization of the sections/subsections but the correspondence wasn't always obvious to me. Again, I think it could all be explained in a much more linear way when the terminology is well-defined in the introduction and it is used in a coherent way throughout the text. For example: it wasn't obvious what you were comparing Metos3D with in Section 7.4. Here you use the expression : ”parallel performance of the TMM” but you never explain what you exactly mean by it. I am familiar with the TMM and it took a while to me to understand that you were comparing Metos3D with the implementation provided by Khatiwala together with the transport matrices you use here. In the Introduction you briefly describe this comparison at lines 133-136 where you use the expression :” the one used in Khatiwala (2013)”. Here is where you should assign to “the one used in Khatiwala (2013)” a name and stick to it in the rest of the manuscript.

-Section 6.1. It is an improvement from the previous version. The use of the schematic in Figure 1 (note that numbering of the figures start from 11) helps to follow the description of the implementation however, the terminology used in this section does not correspond with that used in the figure. For example, at lines 470 and 472, the words “debug” and “utilization” are used in italics and are actually called “layers” however there's no trace of them in the Figure. In general, as a suggestion , I would simplify the description, try to outline the main message of this section and leave the details for the appendix.

-Section 6.3 concerns only the interpolation of the transport matrices so it should be specified in the title. Alternatively, you could group all the following parts concerning interpolation under this section. For example Section 6.4 lines 555-569. Also Section 6.5 seems like it could be merged (and shortened with Section 6.3.

-Section 7.3. This part of the analysis is very interesting and very useful for model developers however, I believe it would be useful to present results also in terms of the incremental computing time per tracer vs number of tracers.

Minor comments:

-Introduction, page 1, lines 45-50. These two sentences are incomprehensible to me. I don't understand what is “its intended (intented in the text) later usage”, perhaps try to be more explicit. What does it mean “and mentioned in the name of” ? It seems like this bit of text got lost in there somehow. Rephrase all this part with a clear structure.

-Introduction, page 2, line 105. “Except for the latter.....” what latter?

-Section 5, line 430. Maybe you mean “current” instead of “actual”?

-Section 6.3, lines 528-535. How is this different from what is commonly done (I guess in the Khatiwala implementation) ? Maybe try to explain (explicitly) how this procedure is different from the common practice and why is preferred.

-Be careful with the order of the Figures as they are mentioned in the text, for example, at line 728 you mention Figure 19 before Figures 14 1nd 15.

-Section 6.4, lines 570-579. Why are there two different “data alignments” ? I could not figure out what you mean here. Maybe this should have resulted clear from the previous sections but it did not so this paragraph sounds like coming out of nowhere to me. Also in this paragraph you mention the “software utilization layer” of which there is no trace in Figure 1.

-Section 7.1.1, lines 653-668. This part looks like it could go in the Appendix or directly in the instructions.

-Section 7.2, lines 738-744. Mind to elaborate a little bit further on the cause of those peaks?

-Section 7.4, lines 841-842. You should explain clearly here what you mean by theoretical efficiency.

-Lines 978-980. This sentence is not clear. Consider rewording.

Hide

RR by Anonymous Referee #2 (25 Apr 2016)

ED: Reconsider after major revisions (03 May 2016) by Andrew Yool

AR by Jaroslaw Piwonski on behalf of the Authors (15 Jun 2016) Manuscript

ED: Reconsider after major revisions (07 Jul 2016) by Andrew Yool

AR by Jaroslaw Piwonski on behalf of the Authors (21 Jul 2016) Manuscript

ED: Referee Nomination & Report Request started (05 Aug 2016) by Andrew Yool

RR by Anonymous Referee #1 (29 Aug 2016)

RR by Momme Butenschön (20 Sep 2016)

ED: Publish subject to technical corrections (20 Sep 2016) by Andrew Yool

AR by Jaroslaw Piwonski on behalf of the Authors (27 Sep 2016) Author's response Manuscript

Short summary

In order to fundamentally tackle the problem of parameter identification for marine ecosystem models in 3-D, we introduced a general biogeochemical programming interface that fits into the optimization context. Moreover, we implemented a comprehensive parallel solver software for periodic steady states that uses the interface to couple marine ecosystem models to a transport matrix driver. We validated the new implementation using a hierarchy of biogeochemical models.