the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 11 Jul 2023
Implementing a coral reef CaCO3 production module in the iLOVECLIM climate model
Abstract. Coral reef development is intricately linked to both climate and the concentration of atmospheric CO2, specifically through temperature and carbonate chemistry in the upper ocean. In turn, the calcification of corals modifies the concentration of dissolved inorganic carbon and total alkalinity in the ocean, impacting air-sea gas exchange, atmospheric CO2 concentration, and ultimately the climate. This retroaction between atmospheric conditions and coral biogeochemistry can only be accounted for with a coupled coral-carbon-climate model. Here we present the implementation of a coral reef calcification module into an Earth System model. Simulated coral reef production of the calcium carbonate mineral aragonite depends on photosynthetically active radiation, nutrient concentrations, salinity, temperature and the aragonite saturation state. An ensemble of 210 parameter perturbation simulations was performed to identify carbonate production parameter values that optimise the simulated distribution of coral reefs and associated carbonate production. The tuned model simulates the presence of coral reefs and regional-to-global carbonate production values in good agreement with data-based estimates. The model enables assessment of past and future coral-climate coupling on seasonal to millennial timescales, highlighting how climatic trends and variability may affect reef development and the resulting climate-carbon feedback.
-
Notice on discussion status
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
-
Preprint
(2000 KB)
-
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(2000 KB) - Metadata XML
- BibTeX
- EndNote
- Final revised paper
Journal article(s) based on this preprint
Interactive discussion
Status: closed
-
CC1: 'Quick comment on PAR data', Jean-Pierre Gattuso, 21 Jul 2023
I will read this paper with great interest. You may want to consider using PAR at the bottom (with KD PAR rather than K490). A global dataset with 4.6 km resolution at the equator is available here:
- Gattuso J.-P., Gentili B., Antoine D. & Doxaran D., 2020. Global distribution of photosynthetically available radiation on the seafloor. Earth System Science Data 12:1697-1709. http://dx.doi.org/10.5194/essd-12-1697-2020
- Gentili, B.; Gattuso, J.-P. (2020): Photosynthetically available radiation (PAR) on the seafloor calculated from 21 years of ocean colour satellite data. PANGAEA, https://doi.org/10.1594/PANGAEA.910898
I doubt that using phytoplankton biomass and productivity, which are notoriously very low in coral reef areas, would provide better estimates of the light attenuation coefficient at such large spatial scale than using satelitte data. Note that the preferred unit for PAR is μmol photons m-2 s-1 (μmol m-2 s-1) and that EGU journals use negative exponents in units: μmol l-1 rather than μmol/l.
Citation: https://doi.org/10.5194/egusphere-2023-1162-CC1 -
AC1: 'Reply on CEC1', Nathaelle Bouttes, 24 Aug 2023
Dear editor,
We are sorry we did not comply with the policies. We have modified the manuscript accordingly.
Following the instructions, we have:
- added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
We have also added the version numbers in the next, as well as the version number of iLOVECLIM (version 1.1.6). - provided a repository for the iLOVECLIM code for the reviewers by email
- made available the outputs from the model simulations used in the figures on zenodo (doi: 5281/zenodo.8279283), the data can be accessed at: https://doi.org/10.5281/zenodo.8279283
Nathaelle Bouttes
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC1 - added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
-
AC2: 'Reply on CC1', Nathaelle Bouttes, 09 Apr 2024
We thank Jean-Pierre Gattuso for his comment. We have corrected the units following his advice. As for the PAR at the bottom, because we use PAR computed by the model we prefer to use K490.
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC2
-
CEC1: 'Comment on egusphere-2023-1162', Juan Antonio Añel, 03 Aug 2023
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlYour submission contains several flaws that must be addressed, specifically:- As the handling topical editor mentioned, the title must contain the version number and the name of the code that you have developed (iCORAL). Also, in the manuscript, you must clarify the iLOVECLIM version you use for your work.- You need to provide a repository for the iLOVECLIM version you use for your work. It is not enough to provide the iCoral module code, as it is only possible to test it with the remainder of the model.- The "Data Availability" section states that the data will be available in Zenodo. We do not admit this. Our policy is clear and requests that all the assets for a submitted manuscript must be available and public at submission time.I note that your manuscript should not have been accepted in Discussions, given this lack of compliance with our policy. Therefore, the current situation with your manuscript is irregular. In this way, if you do not fix this problem, we will have to reject your manuscript for publication in our journal.Therefore, please, provide the details (link and DOI) about versions and code and the input and output data used in your work, public in one of the appropriate repositories. You must do it by replying to this comment with the relevant information as soon as possible, as it should be available before the Discussions stage.Juan A. AñelGeosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2023-1162-CEC1 -
AC1: 'Reply on CEC1', Nathaelle Bouttes, 24 Aug 2023
Dear editor,
We are sorry we did not comply with the policies. We have modified the manuscript accordingly.
Following the instructions, we have:
- added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
We have also added the version numbers in the next, as well as the version number of iLOVECLIM (version 1.1.6). - provided a repository for the iLOVECLIM code for the reviewers by email
- made available the outputs from the model simulations used in the figures on zenodo (doi: 5281/zenodo.8279283), the data can be accessed at: https://doi.org/10.5281/zenodo.8279283
Nathaelle Bouttes
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC1 - added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
-
CC2: 'Reply on CEC1', Didier Roche, 28 Aug 2023
Dear Juan Anel,
Being responsible for the iLOVECLIM special issue, I would like to comment on your latest position on the availability of the code of iLOVECLIM in the current manuscript namely that "the problem with your manuscript continues to be that you are not publishing all the code necessary to reproduce your manuscript. That is, you should publish the code of iLOVECLIM."
To my knowledge, the current policy of GMD is what is defined in the Editorial v1.2 ( https://gmd.copernicus.org/articles/12/2215/2019/ ).
On the iLOVECLIM side, the present manuscript relies on the different versions that have been published according to that policy, with the caveat that we do not hold the Licensing on all the pieces of the iLOVECLIM code and that therefore we are unable to provide the code on an open source basis. I have been working on the topic and still hope to do so in the future, but it is not the case at present.
This has been reflected in subsequent publications of the iLOVECLIM Special Issue, for example Quiquet et al., 2018:Code availability. The iLOVECLIM source code is based on the
LOVECLIM model version 1.2 whose code is accessible at http://
www.elic.ucl.ac.be/modx/elic/index.php?id=289 (UCL, 2018). The
developments on the iLOVECLIM source code are hosted at http:
//forge.ipsl.jussieu.fr/ludus (IPSL, 2018), but are not publicly avail-
able due to copyright restrictions. Access can be granted on demand
by request to D. M. Roche (didier.roche@lsce.ipsl.fr) to those who
conduct research in collaboration with the iLOVECLIM user group.
For this work we used the model at revision 706This approach is at present compliant with the Editorial v1.2 of the GMD journal that states :
" All manuscripts must at a minimum provide confidential access to the code and data developed in the manuscript for the editor and reviewers in order to enable peer review (see Appendix A1)."
"In the case where the new code and data described in the paper are not restricted but are part of a larger code and data structure that has other restricted elements, it is still possible to satisfy the GMD requirements by making the new parts of the code and data available. As the result is usually not a coherent model which can be expected to compile, authors sometimes prefer to upload these code fragments to the supplement rather than to a repository. Authors may have to remove restricted elements from their model code base, but in the meantime this remains an acceptable if somewhat unsatisfactory solution."
The latest changes proposed by Bouttes et al. in the comment above do match those two definitiions unless I am mistaken, since the complete code has been made available to the reviewers under the cover of the managing editor.
Coule you then please highlight where the issue stills stands for this manuscript (if at all)?
Best wishes,
Didier ROCHE
Citation: https://doi.org/10.5194/egusphere-2023-1162-CC2 -
CEC2: 'Reply on CC2', Juan Antonio Añel, 28 Aug 2023
Dear Didier, dear authors,
Many thanks for the explanation provided regarding the iLOVECLIM model.
I find especially relevant the explanation that you can not share parts of the model because their licenses do not permit it, and that you do not own the copyright. I understand that this is the meaning of "hold the licensing". This is reasonable, and acceptable according to our policy. Also, it is great to know that you are working to solve the situation.
My only concern now is that the links that you provide for the code, are simple web servers, and although they seem to have been working since 2018, and continue to work, they are not the kind of repository that we trust as listed in the policy. It would be desirable that you make copies of them in Zenodo private repositories, which, additionally, will provide a DOI. In this way, you would continue to have the distribution of the code under control, and we can be sure that it is properly stored and will not be lost in future. This is not mentioned in our policy, but we have been asking for it since some time ago to authors, as a best practice.
Otherwise, with your explanation, I agree that your manuscript is now compliant with the policy, and the issue is solved with the information that you have provided.
Regards,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2023-1162-CEC2
-
CEC2: 'Reply on CC2', Juan Antonio Añel, 28 Aug 2023
-
AC1: 'Reply on CEC1', Nathaelle Bouttes, 24 Aug 2023
-
CC3: 'Comment on egusphere-2023-1162', David Archer, 20 Sep 2023
The goal of this work, to create a coastal CaCO3 coral module for a long-term climate / carbon cycle code, is extremely useful and strategic. There is no doubt that corals must have had a strong impact on the carbon cycle evolution through time. The model construction and validation are thorough and thoughtful, and the presentation is clear and polished. The actual scientific fruits of this work will come in future simulations of the interactions of the corals with the rest of the climate system; the current paper is more of a model description and tuning relative to present-day data. Which is necessary and fine. I'm not coming up with many suggestions for improvement, but rather an endorsement of publication as is, as far as I am concerned.
Citation: https://doi.org/10.5194/egusphere-2023-1162-CC3 -
AC3: 'Reply on CC3', Nathaelle Bouttes, 09 Apr 2024
We thank David Archer for his support.
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC3
-
AC3: 'Reply on CC3', Nathaelle Bouttes, 09 Apr 2024
-
RC1: 'Comment on egusphere-2023-1162', Anonymous Referee #1, 03 Nov 2023
Review: Implementing a coral reef CaCO3 production module in the iLOVECLIM climate model
Bouttes et al.**
GENERAL COMMENTS
**This paper presents a new model of coral reef carbonate production, designed to be coupled to earth system model frameworks and allowing for the simulation of long-term feedbacks between coral calcification and the larger carbon cycle. I am not aware of any other models of coral calcification that are designed to be run in a fully-coupled manner with ESMs, and as such agree that this model fills a previously unfilled niche in climate system modeling. While the impacts of changing carbonate system properties on biology is often simulated, the feedback effects of that biology on the oceanic and atmospheric carbon are much less often addressed, and may become increasingly important as research into novel fields like carbon dioxide removal increases. Overall, this was a clearly-written paper. While the results are somewhat preliminary, covering the initial setup and some short simulations to verify its ability to replicate current conditions, I think that even as a proof of concept this will be a valuable contribution to the field. There are a few places where the model details and the thought processes leading to those details could be expanded and clarified, which I include in my specific comments below.
My one broader comment for this paper is in regard to how iCORAL is alternatively framed as either 1) a coral module specific to the iLOVECLIM framework vs 2) a module more generically available for use in ESMs as a whole. Several of the model implementation choices (e.g. subgridding the bathymetry to compensate for low horizontal resolution, adding temperature variability in the tropics) are clearly tailored to iLOVECLIM. Also, the source code is not written in a standalone, modular manner (it loads many of its variables through external fortran modules from the wider iLOVECLIM code*, many parameters are hard-coded, etc.); porting to a new ESM would be a non-trivial task. I suggest revising the text where relevant to clarify that the algorithms and concepts behind the model may be applicable more widely, but significant work would be necessary to port, test, and validate the model under a new ESM coupling.
*Regarding the source code, the author comments (CEC1) imply that they made iLOVECLIM source code available to referees, but I did not receive any documents apart from those available for public review. Therefore, I have not been able to check whether the coral_mod_paper.f90 code (as linked in the Code availability section) compiles and runs in that context. However, the coral_mod module itself is clearly written -- well-commented, cleanly organized and formatted -- and seems mathematically sound.
**
SPECIFIC COMMENTS
**Section 2.1: The iLOVECLIM setup description could use a bit more detail. First, I wasn't entirely clear what the relationship between iLOVECLIM and LOVECLIM was. Based on the iLOVECLIM GMD special issue text (https://gmd.copernicus.org/articles/special_issue30.html), I gather that iLOVECLIM derived from LOVECLIM, minus ice (and possibly minus ocean carbon/bio?), then developed independently? A quick summary of this history in the paper would be useful to orient readers. Also, is the ocean carbon cycle model described in this paper a standard part of the iLOVECLIM configuration? I believe you're using the HAMOCC model for ocean biogeochemistry; can you specify which version? Are there any other parts of your iLOVECLIM configuration (other than the addition of iCORAL) that differs from other published implementations?
Line 91-92: "Photosynthesis takes place in the euphotic zone in the upper 100 meters." Can you clarify whether this depth is prescribed or an emergent property of the model?
Line 95: Given that iCORAL is an extension of ReefHab, a quick description of that model would be useful. It sounds like ReefHab is a classic coral production model, and iCORAL uses the same basic equations but adapted to use ESM-derived input rather than just observational datasets (and with some expanded constraints like the bleaching addition.) Saying this explicitly would help orient readers unfamiliar with ReefHab.
Figure 1. I didn't find this figure particularly useful; the graphical elements don't provide any new information. I suggest either turning this into a more information-dense schematic (perhaps diagraming the input from coupled model components vs. offline datasets, and the additional pre-preprocessing steps applied before feeding that data into iCORAL, etc.) or eliminating it.
Line 110: Perhaps clarify that the production depth is defined as the depth at which light is at the Imin level? Readers unfamiliar with the typical light attenuation equation may not immediately parse this detail.
Line 115: Please provide more detail about how the K490 coefficients were chosen and calculated. What specific MODIS data was used to construct the binned data? Did you use the entire mission composite, and if so, through what dates? At what horizontal resolution (4km or 9km)? How were these data matched to the iLOVECLIM horizontal grid? Other satellite-based algorithms are available to calculate this attenuation coefficient near turbid water (for example, NOAA's version based on Tomlinson et al., 2019: https://doi.org/10.1080/2150704X.2018.1536301); were these considered?
Also, I'm curious about the decision to use a satellite product to derive these coefficients, rather than deriving the attenuation directly from the model itself (i.e. as a function of chlorophyll + clear-water attenuation, with the latter tied to the simulated phytoplankton group). Given the intent to use this model for paleo-scale simulations, I'm concerned that this choice may decouple the model's simulated chl from the prescribed attenuation coefficients that are at least in part a function of satellite-era chl concentration. I recognize that using a prognostic base for this calculation comes with its own set of difficulties (requiring skillful phytoplankton simulation and some estimate of the CDOM/sediment/etc. distribution), but I think this choice warrants some additional discussion in the paper. You do later mention this as a caveat in the Discussion section 4.1 (Model caveats), but I'd like to see it addressed more fully, either in the Methods or in that caveats section.
On a related note, is the iLOVECLIM configuration capable of responding to long-term changes in wetting/drying? I.e. if sea level rises, can grid cells previously designated as land become inundated, or vice versa? If so, how does the iCORAL model handle parameterization of grid cells without satellite-era data to use? Given that an inundation-related scenario is presented as a driving theory for the potential importance of coral reefs in the carbon cycle, this is a key technical point in the potential usefulness of this model setup.
Line 155-160: The description of the 1-m vertical subgridding could be clearer; it took me a few readings to figure out what was being done. Using terminology like "vertical resolution" and "depth interval" was a little misleading to me, since initially I interpreted this as a sub-gridding of the water column, rather than a pairing of each 3-deg grid cell with its subgrid-scale bathymetry distribution.
Line 243: Criv and Ariv are never explicitly defined; I assume those are the river input flux of DIC and Alkalinity, respectively?
Line 259: "AR(p)" may be too jargon-y for a non-statistical-modeling audience; please provide a quick definition of this model type and what the model order (p) refers to. Also, you mention supplementary material here, but I could not locate any supplementary material associated with this manuscript.
Line 263: Where did the values of 0.90 and 0.28 come from? Are they standard values or were they derived from the fitting process?
Figure 4: Anomaly plots would be helpful to allow quicker direct comparison between column 1 and 2.
Lines 319-322: You mention that coral overproduction in the model might be due to lack of riverine nutrient input leading to lack of competition from macroalgae. While that is one possible source, lower-resolution models (even 1-deg) tend to underestimate coastal pelagic production due to poor resolution of shelf dynamics, which could alter the conditions in these regions. And it doesn't appear that this model simulates macroalgae at all, so even with improved riverine input that competitive pressure would be missing in the simulations. A bit more discussion of the possible drivers of oversimulation of coral could be useful here.
Line 323: "might not be present in the observed data." Are you saying that these types of features might exist in the real world but not be captured by this particular dataset? Or that the model is simulating a type of isolated coral reef that probably doesn't exist in the real world?
Lines 432-434: This statement implies that perhaps the answer to my inundation question above is no, the model cannot handle wetting/drying. It's not clear to me how one would reparameterize coral growth parameters to be dependent on sea level without explicitly allowing for this; can you expand on this idea?
**
TECHNICAL COMMENTS
**Equations: Equation numbers would be nice (possibly not a requirement for this journal?).
Line 266, 277, etc: Use of present perfect rather than past tense read a little strangely to me.
Figure 2: Is this just presence/absence data? Please clarify in the caption or add an appropriate legend.
Fig. 7a: I suggest adding the blue/purple highlights to this panel for consistency with Fig 7b, 7c, 8, and 9.
Citation: https://doi.org/10.5194/egusphere-2023-1162-RC1 - AC5: 'Reply on RC1', Nathaelle Bouttes, 09 Apr 2024
-
RC2: 'Comment on egusphere-2023-1162', Andy Ridgwell, 22 Jan 2024
- AC6: 'Reply on RC2', Nathaelle Bouttes, 09 Apr 2024
- AC4: 'Comment on egusphere-2023-1162', Nathaelle Bouttes, 09 Apr 2024
Interactive discussion
Status: closed
-
CC1: 'Quick comment on PAR data', Jean-Pierre Gattuso, 21 Jul 2023
I will read this paper with great interest. You may want to consider using PAR at the bottom (with KD PAR rather than K490). A global dataset with 4.6 km resolution at the equator is available here:
- Gattuso J.-P., Gentili B., Antoine D. & Doxaran D., 2020. Global distribution of photosynthetically available radiation on the seafloor. Earth System Science Data 12:1697-1709. http://dx.doi.org/10.5194/essd-12-1697-2020
- Gentili, B.; Gattuso, J.-P. (2020): Photosynthetically available radiation (PAR) on the seafloor calculated from 21 years of ocean colour satellite data. PANGAEA, https://doi.org/10.1594/PANGAEA.910898
I doubt that using phytoplankton biomass and productivity, which are notoriously very low in coral reef areas, would provide better estimates of the light attenuation coefficient at such large spatial scale than using satelitte data. Note that the preferred unit for PAR is μmol photons m-2 s-1 (μmol m-2 s-1) and that EGU journals use negative exponents in units: μmol l-1 rather than μmol/l.
Citation: https://doi.org/10.5194/egusphere-2023-1162-CC1 -
AC1: 'Reply on CEC1', Nathaelle Bouttes, 24 Aug 2023
Dear editor,
We are sorry we did not comply with the policies. We have modified the manuscript accordingly.
Following the instructions, we have:
- added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
We have also added the version numbers in the next, as well as the version number of iLOVECLIM (version 1.1.6). - provided a repository for the iLOVECLIM code for the reviewers by email
- made available the outputs from the model simulations used in the figures on zenodo (doi: 5281/zenodo.8279283), the data can be accessed at: https://doi.org/10.5281/zenodo.8279283
Nathaelle Bouttes
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC1 - added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
-
AC2: 'Reply on CC1', Nathaelle Bouttes, 09 Apr 2024
We thank Jean-Pierre Gattuso for his comment. We have corrected the units following his advice. As for the PAR at the bottom, because we use PAR computed by the model we prefer to use K490.
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC2
-
CEC1: 'Comment on egusphere-2023-1162', Juan Antonio Añel, 03 Aug 2023
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".https://www.geoscientific-model-development.net/policies/code_and_data_policy.htmlYour submission contains several flaws that must be addressed, specifically:- As the handling topical editor mentioned, the title must contain the version number and the name of the code that you have developed (iCORAL). Also, in the manuscript, you must clarify the iLOVECLIM version you use for your work.- You need to provide a repository for the iLOVECLIM version you use for your work. It is not enough to provide the iCoral module code, as it is only possible to test it with the remainder of the model.- The "Data Availability" section states that the data will be available in Zenodo. We do not admit this. Our policy is clear and requests that all the assets for a submitted manuscript must be available and public at submission time.I note that your manuscript should not have been accepted in Discussions, given this lack of compliance with our policy. Therefore, the current situation with your manuscript is irregular. In this way, if you do not fix this problem, we will have to reject your manuscript for publication in our journal.Therefore, please, provide the details (link and DOI) about versions and code and the input and output data used in your work, public in one of the appropriate repositories. You must do it by replying to this comment with the relevant information as soon as possible, as it should be available before the Discussions stage.Juan A. AñelGeosci. Model Dev. Executive EditorCitation: https://doi.org/10.5194/egusphere-2023-1162-CEC1 -
AC1: 'Reply on CEC1', Nathaelle Bouttes, 24 Aug 2023
Dear editor,
We are sorry we did not comply with the policies. We have modified the manuscript accordingly.
Following the instructions, we have:
- added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
We have also added the version numbers in the next, as well as the version number of iLOVECLIM (version 1.1.6). - provided a repository for the iLOVECLIM code for the reviewers by email
- made available the outputs from the model simulations used in the figures on zenodo (doi: 5281/zenodo.8279283), the data can be accessed at: https://doi.org/10.5281/zenodo.8279283
Nathaelle Bouttes
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC1 - added the name of the module with its version number (iCORAL version 1.0) in the title, which is now: “Implementing the iCORAL (version 1.0) coral reef CaCO3 production module in the iLOVECLIM climate model”.
-
CC2: 'Reply on CEC1', Didier Roche, 28 Aug 2023
Dear Juan Anel,
Being responsible for the iLOVECLIM special issue, I would like to comment on your latest position on the availability of the code of iLOVECLIM in the current manuscript namely that "the problem with your manuscript continues to be that you are not publishing all the code necessary to reproduce your manuscript. That is, you should publish the code of iLOVECLIM."
To my knowledge, the current policy of GMD is what is defined in the Editorial v1.2 ( https://gmd.copernicus.org/articles/12/2215/2019/ ).
On the iLOVECLIM side, the present manuscript relies on the different versions that have been published according to that policy, with the caveat that we do not hold the Licensing on all the pieces of the iLOVECLIM code and that therefore we are unable to provide the code on an open source basis. I have been working on the topic and still hope to do so in the future, but it is not the case at present.
This has been reflected in subsequent publications of the iLOVECLIM Special Issue, for example Quiquet et al., 2018:Code availability. The iLOVECLIM source code is based on the
LOVECLIM model version 1.2 whose code is accessible at http://
www.elic.ucl.ac.be/modx/elic/index.php?id=289 (UCL, 2018). The
developments on the iLOVECLIM source code are hosted at http:
//forge.ipsl.jussieu.fr/ludus (IPSL, 2018), but are not publicly avail-
able due to copyright restrictions. Access can be granted on demand
by request to D. M. Roche (didier.roche@lsce.ipsl.fr) to those who
conduct research in collaboration with the iLOVECLIM user group.
For this work we used the model at revision 706This approach is at present compliant with the Editorial v1.2 of the GMD journal that states :
" All manuscripts must at a minimum provide confidential access to the code and data developed in the manuscript for the editor and reviewers in order to enable peer review (see Appendix A1)."
"In the case where the new code and data described in the paper are not restricted but are part of a larger code and data structure that has other restricted elements, it is still possible to satisfy the GMD requirements by making the new parts of the code and data available. As the result is usually not a coherent model which can be expected to compile, authors sometimes prefer to upload these code fragments to the supplement rather than to a repository. Authors may have to remove restricted elements from their model code base, but in the meantime this remains an acceptable if somewhat unsatisfactory solution."
The latest changes proposed by Bouttes et al. in the comment above do match those two definitiions unless I am mistaken, since the complete code has been made available to the reviewers under the cover of the managing editor.
Coule you then please highlight where the issue stills stands for this manuscript (if at all)?
Best wishes,
Didier ROCHE
Citation: https://doi.org/10.5194/egusphere-2023-1162-CC2 -
CEC2: 'Reply on CC2', Juan Antonio Añel, 28 Aug 2023
Dear Didier, dear authors,
Many thanks for the explanation provided regarding the iLOVECLIM model.
I find especially relevant the explanation that you can not share parts of the model because their licenses do not permit it, and that you do not own the copyright. I understand that this is the meaning of "hold the licensing". This is reasonable, and acceptable according to our policy. Also, it is great to know that you are working to solve the situation.
My only concern now is that the links that you provide for the code, are simple web servers, and although they seem to have been working since 2018, and continue to work, they are not the kind of repository that we trust as listed in the policy. It would be desirable that you make copies of them in Zenodo private repositories, which, additionally, will provide a DOI. In this way, you would continue to have the distribution of the code under control, and we can be sure that it is properly stored and will not be lost in future. This is not mentioned in our policy, but we have been asking for it since some time ago to authors, as a best practice.
Otherwise, with your explanation, I agree that your manuscript is now compliant with the policy, and the issue is solved with the information that you have provided.
Regards,
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2023-1162-CEC2
-
CEC2: 'Reply on CC2', Juan Antonio Añel, 28 Aug 2023
-
AC1: 'Reply on CEC1', Nathaelle Bouttes, 24 Aug 2023
-
CC3: 'Comment on egusphere-2023-1162', David Archer, 20 Sep 2023
The goal of this work, to create a coastal CaCO3 coral module for a long-term climate / carbon cycle code, is extremely useful and strategic. There is no doubt that corals must have had a strong impact on the carbon cycle evolution through time. The model construction and validation are thorough and thoughtful, and the presentation is clear and polished. The actual scientific fruits of this work will come in future simulations of the interactions of the corals with the rest of the climate system; the current paper is more of a model description and tuning relative to present-day data. Which is necessary and fine. I'm not coming up with many suggestions for improvement, but rather an endorsement of publication as is, as far as I am concerned.
Citation: https://doi.org/10.5194/egusphere-2023-1162-CC3 -
AC3: 'Reply on CC3', Nathaelle Bouttes, 09 Apr 2024
We thank David Archer for his support.
Citation: https://doi.org/10.5194/egusphere-2023-1162-AC3
-
AC3: 'Reply on CC3', Nathaelle Bouttes, 09 Apr 2024
-
RC1: 'Comment on egusphere-2023-1162', Anonymous Referee #1, 03 Nov 2023
Review: Implementing a coral reef CaCO3 production module in the iLOVECLIM climate model
Bouttes et al.**
GENERAL COMMENTS
**This paper presents a new model of coral reef carbonate production, designed to be coupled to earth system model frameworks and allowing for the simulation of long-term feedbacks between coral calcification and the larger carbon cycle. I am not aware of any other models of coral calcification that are designed to be run in a fully-coupled manner with ESMs, and as such agree that this model fills a previously unfilled niche in climate system modeling. While the impacts of changing carbonate system properties on biology is often simulated, the feedback effects of that biology on the oceanic and atmospheric carbon are much less often addressed, and may become increasingly important as research into novel fields like carbon dioxide removal increases. Overall, this was a clearly-written paper. While the results are somewhat preliminary, covering the initial setup and some short simulations to verify its ability to replicate current conditions, I think that even as a proof of concept this will be a valuable contribution to the field. There are a few places where the model details and the thought processes leading to those details could be expanded and clarified, which I include in my specific comments below.
My one broader comment for this paper is in regard to how iCORAL is alternatively framed as either 1) a coral module specific to the iLOVECLIM framework vs 2) a module more generically available for use in ESMs as a whole. Several of the model implementation choices (e.g. subgridding the bathymetry to compensate for low horizontal resolution, adding temperature variability in the tropics) are clearly tailored to iLOVECLIM. Also, the source code is not written in a standalone, modular manner (it loads many of its variables through external fortran modules from the wider iLOVECLIM code*, many parameters are hard-coded, etc.); porting to a new ESM would be a non-trivial task. I suggest revising the text where relevant to clarify that the algorithms and concepts behind the model may be applicable more widely, but significant work would be necessary to port, test, and validate the model under a new ESM coupling.
*Regarding the source code, the author comments (CEC1) imply that they made iLOVECLIM source code available to referees, but I did not receive any documents apart from those available for public review. Therefore, I have not been able to check whether the coral_mod_paper.f90 code (as linked in the Code availability section) compiles and runs in that context. However, the coral_mod module itself is clearly written -- well-commented, cleanly organized and formatted -- and seems mathematically sound.
**
SPECIFIC COMMENTS
**Section 2.1: The iLOVECLIM setup description could use a bit more detail. First, I wasn't entirely clear what the relationship between iLOVECLIM and LOVECLIM was. Based on the iLOVECLIM GMD special issue text (https://gmd.copernicus.org/articles/special_issue30.html), I gather that iLOVECLIM derived from LOVECLIM, minus ice (and possibly minus ocean carbon/bio?), then developed independently? A quick summary of this history in the paper would be useful to orient readers. Also, is the ocean carbon cycle model described in this paper a standard part of the iLOVECLIM configuration? I believe you're using the HAMOCC model for ocean biogeochemistry; can you specify which version? Are there any other parts of your iLOVECLIM configuration (other than the addition of iCORAL) that differs from other published implementations?
Line 91-92: "Photosynthesis takes place in the euphotic zone in the upper 100 meters." Can you clarify whether this depth is prescribed or an emergent property of the model?
Line 95: Given that iCORAL is an extension of ReefHab, a quick description of that model would be useful. It sounds like ReefHab is a classic coral production model, and iCORAL uses the same basic equations but adapted to use ESM-derived input rather than just observational datasets (and with some expanded constraints like the bleaching addition.) Saying this explicitly would help orient readers unfamiliar with ReefHab.
Figure 1. I didn't find this figure particularly useful; the graphical elements don't provide any new information. I suggest either turning this into a more information-dense schematic (perhaps diagraming the input from coupled model components vs. offline datasets, and the additional pre-preprocessing steps applied before feeding that data into iCORAL, etc.) or eliminating it.
Line 110: Perhaps clarify that the production depth is defined as the depth at which light is at the Imin level? Readers unfamiliar with the typical light attenuation equation may not immediately parse this detail.
Line 115: Please provide more detail about how the K490 coefficients were chosen and calculated. What specific MODIS data was used to construct the binned data? Did you use the entire mission composite, and if so, through what dates? At what horizontal resolution (4km or 9km)? How were these data matched to the iLOVECLIM horizontal grid? Other satellite-based algorithms are available to calculate this attenuation coefficient near turbid water (for example, NOAA's version based on Tomlinson et al., 2019: https://doi.org/10.1080/2150704X.2018.1536301); were these considered?
Also, I'm curious about the decision to use a satellite product to derive these coefficients, rather than deriving the attenuation directly from the model itself (i.e. as a function of chlorophyll + clear-water attenuation, with the latter tied to the simulated phytoplankton group). Given the intent to use this model for paleo-scale simulations, I'm concerned that this choice may decouple the model's simulated chl from the prescribed attenuation coefficients that are at least in part a function of satellite-era chl concentration. I recognize that using a prognostic base for this calculation comes with its own set of difficulties (requiring skillful phytoplankton simulation and some estimate of the CDOM/sediment/etc. distribution), but I think this choice warrants some additional discussion in the paper. You do later mention this as a caveat in the Discussion section 4.1 (Model caveats), but I'd like to see it addressed more fully, either in the Methods or in that caveats section.
On a related note, is the iLOVECLIM configuration capable of responding to long-term changes in wetting/drying? I.e. if sea level rises, can grid cells previously designated as land become inundated, or vice versa? If so, how does the iCORAL model handle parameterization of grid cells without satellite-era data to use? Given that an inundation-related scenario is presented as a driving theory for the potential importance of coral reefs in the carbon cycle, this is a key technical point in the potential usefulness of this model setup.
Line 155-160: The description of the 1-m vertical subgridding could be clearer; it took me a few readings to figure out what was being done. Using terminology like "vertical resolution" and "depth interval" was a little misleading to me, since initially I interpreted this as a sub-gridding of the water column, rather than a pairing of each 3-deg grid cell with its subgrid-scale bathymetry distribution.
Line 243: Criv and Ariv are never explicitly defined; I assume those are the river input flux of DIC and Alkalinity, respectively?
Line 259: "AR(p)" may be too jargon-y for a non-statistical-modeling audience; please provide a quick definition of this model type and what the model order (p) refers to. Also, you mention supplementary material here, but I could not locate any supplementary material associated with this manuscript.
Line 263: Where did the values of 0.90 and 0.28 come from? Are they standard values or were they derived from the fitting process?
Figure 4: Anomaly plots would be helpful to allow quicker direct comparison between column 1 and 2.
Lines 319-322: You mention that coral overproduction in the model might be due to lack of riverine nutrient input leading to lack of competition from macroalgae. While that is one possible source, lower-resolution models (even 1-deg) tend to underestimate coastal pelagic production due to poor resolution of shelf dynamics, which could alter the conditions in these regions. And it doesn't appear that this model simulates macroalgae at all, so even with improved riverine input that competitive pressure would be missing in the simulations. A bit more discussion of the possible drivers of oversimulation of coral could be useful here.
Line 323: "might not be present in the observed data." Are you saying that these types of features might exist in the real world but not be captured by this particular dataset? Or that the model is simulating a type of isolated coral reef that probably doesn't exist in the real world?
Lines 432-434: This statement implies that perhaps the answer to my inundation question above is no, the model cannot handle wetting/drying. It's not clear to me how one would reparameterize coral growth parameters to be dependent on sea level without explicitly allowing for this; can you expand on this idea?
**
TECHNICAL COMMENTS
**Equations: Equation numbers would be nice (possibly not a requirement for this journal?).
Line 266, 277, etc: Use of present perfect rather than past tense read a little strangely to me.
Figure 2: Is this just presence/absence data? Please clarify in the caption or add an appropriate legend.
Fig. 7a: I suggest adding the blue/purple highlights to this panel for consistency with Fig 7b, 7c, 8, and 9.
Citation: https://doi.org/10.5194/egusphere-2023-1162-RC1 - AC5: 'Reply on RC1', Nathaelle Bouttes, 09 Apr 2024
-
RC2: 'Comment on egusphere-2023-1162', Andy Ridgwell, 22 Jan 2024
- AC6: 'Reply on RC2', Nathaelle Bouttes, 09 Apr 2024
- AC4: 'Comment on egusphere-2023-1162', Nathaelle Bouttes, 09 Apr 2024
Peer review completion
Journal article(s) based on this preprint
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 582 | 225 | 65 | 872 | 43 | 41 |
- HTML: 582
- PDF: 225
- XML: 65
- Total: 872
- BibTeX: 43
- EndNote: 41
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Cited
1 citations as recorded by crossref.
Nathaelle Bouttes
Lester Kwiatkowski
Manon Berger
Victor Brovkin
Guy Munhoven
The requested preprint has a corresponding peer-reviewed final revised paper. You are encouraged to refer to the final revised version.
- Preprint
(2000 KB) - Metadata XML