the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Technical note: A new online tool for δ18O-temperature conversions
Daniel E. Gaskell
Pincelli M. Hull
Abstract. The stable oxygen isotopic composition of marine carbonates (δ18Oc) is one of the oldest and most widely-used paleothermometers, but interpretation of these data is complicated by the necessity of knowing the δ18O of the source seawater (δ18Ow). The effect of local hydrography (the salinity effect
) is particularly difficult to correct for and may lead to errors of >10°C in sea-surface temperatures if neglected. A variety of methods for calculating δ18Ow have been developed in the literature, but not all are readily accessible to workers. Likewise, temperature estimates are sensitive to a range of other calibration choices (such as calibration species and the inclusion or exclusion of carbonate ion effects) which can require significant effort to intercompare. We present an online tool for δ18O-temperature conversions which provides convenient access to a wide range of calibrations and methods from the literature. Using results from recent isotope-enabled climate simulations, we show that the common method of estimating δ18Ow from sample latitudes likely results in paleotemperature estimates that are too cold by up to 5 °C in the North Atlantic and too hot by up to 5°C in the Southern Ocean during the warmest climate states. Our tool provides a convenient way for workers to examine the effects of alternate calibration and correction procedures on their δ18O-based temperature estimates.
Daniel E. Gaskell and Pincelli M. Hull
Status: final response (author comments only)
-
RC1: 'Comment on cp-2022-74', Brett Metcalfe, 01 Dec 2022
Review: Technical note: A new online tool for ð¿18O by Gaskell and Hull
In “Technical note: A new online tool for ð¿18O” Gaskell and Hull (2022) report on an online tool they have produced for helping practitioners convert ð¿18Oc into palaeotemperature. The tool allows user to define multiple options including their favorite ð¿18Oc-temperature calibration, site latitude /longitude, and estimated ð¿18Osw to produce the results at the click of a series of dropdown menus. Different scenarios can be tested simply by repeating the steps allowing for the sensitivity of the resultant temperature to the calibration methodology to be tested relatively quickly and easily. It would be nice if this sensitivity testing could be made (even) easier (e.g., selecting multiple tests prior to processing) but that would make it complex and I think the simplicity is ideal. All of this is wrapped up in a web based tool meaning that there is no code. Furthermore, to make everyone’s job easier the authors have also incorporated an automatically generated (somewhat) detailed methodology text from the selected options. Making the tool useful for both experienced and new palaeoclimatologists. Such tools can help to contribute to open, transparent, and reproducible science. Therefore, I would recommend publication. However, I do have some recommendations regarding both the tool itself, the code, and the text.
The paper is split into three sections to describe the tool: a rationale (section 1); a description of the tool (section 2); and, a demonstration (section 3). The last section is where I have a bit of a problem as it reads like two technical notes stuck together (section 1 + section 2 vs. section 3). As in rather than the later section being an example for the tool described in this technical note this later section appears more focused on the error associated with the latitudinal method (i.e., see the juxtaposition between line 128-131 and lines 132-140). Reading more like a technical note on ‘stop using the latitudinal method’. For a demonstration I would expect to read more about the rationale for the choices of the tool (line 94-98 as line 99- 104 is a reworded repeat of lines 67-73), what a user can expect, and what they can do rather than choices of data and data-comparison (line 111-115). I don’t have a problem with the results of this section and its perfectly fine to keep in. I just feel like there are features of the tool and sections from the information section of the webpage that are not included for the sake of brevity and so this section could be shortened/reworked. Whilst the instructions to authors for a ‘technical note’ do explicitly state that it shouldn’t be a technical manual - so I understand the author’s rationale - I do believe that pertinent information regarding the tool should be included in the ‘scientific record’ (in the paper or as supplementary materials). For instance, a summary of the various palaeotemperature equations, calibration limits, etc. (for an example see Figure 1 in the supplement to this review) as a table in this text would allow users to select the right palaeotemperature equation(s) rather than exploring this component of the tool ‘at random’. Likewise, assumptions, caveats, and computational tricks that are in the code should be explained to aid transparency and avoid it being a blackbox. I would recommend (see major comments below) that the authors incorporate the comments that can be found in the code into the text, ensure that the method section includes all references including reformulations. As well as consider things like versioning, to ensure that the users can keep up with changes to the tool.
Major comments
Comments in code. The proxy.php script on Github has a whole bunch of comments that should be in the text, as a supplement, etc. For instance lines 1228, 1216, 1301-3, 1430,... etc. all include pertinent information as to what your tool is doing yet some aspects do not appear in the associated methodology text that appears post processing. As such it makes your tool less replicable (especially compared with someone not using your tool) simply by removing some steps or introducing pertinent details or caveats that are not alluded to elsewhere. That has the knock-on effect that a user’s methodology section will also be missing steps.
Reformulations. Similarly to the above comment, I do think you need to incorporate ‘reformulated by’ into the methodology text. For instance, the Kim and O’Neil (1997) equation is the equation reformulated by Bemis et al (1998), there are several reformulated versions in the literature with not all being equivalent (see Figure 1 of this review) so it is important for the user to know which they are using.
References. Likewise, as there is no citation limit (only higher APC) I would cite in this article all of the calibrations, reformulations, etc. that your tool uses (rather than ‘.etc’) as this would also officially recognise those author’s contributions to your tool. Reiterating the point above I would also include all references for reformulations, compilations - e.g., Wilmes (line 1430 in proxy.php) here and in the methodology.
Workflow diagram. A workflow diagram could be useful to visually explain lines 56-89.
Versioning. It would be prudent to incorporate a versioning system and/or last update. Versioning is important for replication, if there is a mistake, correction, etc then users can quickly make changes. I can imagine that once processed an author will be unlikely to keep recalibrating so versioning is useful as a hint for users that they might want to recalibrate their previous datasets. Will a webpage be included that lists the changes to the code (rather than assuming a user will explore the file in github to track changes)?
Bibtex. Can you include a bibtex version of the citations for the methodology rather than/as well the nicely formatted references that appear post processing. You could either just include an additional webpage purely with the references in bibtex format or have a download bibtex button. I ask because whilst you have already done much of a user's work for them, if you want to ensure they cite the original papers then you should make the reference list importable to a reference manager. That way users would have absolutely no reason not to cite the original papers.
Reference code for calibration. Could you give the output a code that encapsulates the various options, e.g., something like c1t1i1s1, i.e., c1 the first option of the calibration menu (malevich et al), t1 the first option of the timescale (Gradstein et al), first option of the ice volume (Rohling et al), and the first option of the correction method (Gaskell et al). So the user can refer directly to which options were selected as there are a lot of dropdown menu steps. By setting up your own reference code you would also ensure ‘interoperability’/ ‘replication’ between users . Then authors could refer to it as “ This calibration was performed online using option’s c1t1i1s1 (Gaskell et al).” or “comparison between c1t1i1s1 and c1t2i1s1 shows little..”
Geographically nearest. You average the nearest lat/lon as specified by the user, can we not get a range/stdev for this as well? I also assume that this is uses ‘nanmean’ to take into account missing values (e.g., land) so there will be variation in N depending on if the site +-lat/lon is open ocean versus close to the coast. Can you inform the user of this? Likewise, as mentioned in the minor comments below, latitude doesn’t change distance but longitude does so using the same longitude plus/minus for different sites won’t (always) be the same area averaged. Again it would be important the user realizes this.
Minor comments
Line 6: could modify to: “However, interpretation of such data is complicated by the necessity of knowing the ð¿18Osw of the source seawater from which CaCO3 is precipitated.”
Line 20: this is a linear calibration but many of the calibrations are quadratic. Would it thus not be more prudent to change this to:
“... empirical calibration in either a quadratic (eq 1) or linear (eq 2) form:
T = a - b*(ð¿18Oc -ð¿18Osw) - c*(ð¿18Oc -ð¿18Osw)^2 (1)
T = a - b(ð¿18Oc -ð¿18Osw) (2)”
Line 25: ‘function of sea level’ its a function of ice volume
Line 29: ‘less reliable’ I would be less diplomatic ‘next to impossible compared with’
Line 36-41: refer to changes in E:P
Line 56: could change to: “Here a new online tool for performing ð¿18Oc-temperature conversion is presented that automates a range…”
Line 58: state format/extension of dataset, “After manually entering or uploading a .csv datasheet…” or “After manually entering or uploading a datasheet of ð¿18Oc in .csv format…”
Line 60: remove ‘etc’ and cite all the calibrations paper and reformulation so as to officially recognise those author’s contributions to your tool.
Line 67-71: this is repeated at line’s 99-104. I would move the text from 99-104 here and not repeat it in section 3.
Line 86-89: state somewhere here that the tool also informs the user if the temperature exceeds the calibration limits.
Line 92/93: Include that you are focusing on the Late Paleocene, Eocene (prior to line 98), and PETM (prior to line 105) for this example from the onset.
Line 104: (also line 73-74) latitude is constant but longitude changes distance, how is this accounted for?
Line 123: change to ‘that are significantly closer to the’
Line 128: ‘explore the sensitivity’ point out to the reader that they have to re-run the tool to explore the sensitivity as there is no method to automatically re-run for different scenarios.
Code/data
Data availability statement of the DeepMip 0.1 proxy database
Clean/tidy up the code, i.e., remove FIXME comments
References
The same references are used for the tool so the following should be checked: Gradstein et al. (2020) either publisher city (San Diego) or country (The Netherlands) is incorrect. Sharp (2017) has 2nd edition twice; Cramer et al, Gaskell et al, Malevich et al, Zhou et al all need superscript for the ð¿18O; Ogg et al needs publisher city
Figures
Figure 1: the lower end of the temperature scale and land are a bit hard to distinguish. Can you not replace the land with a different color? (e.g., to gray)
Figure 2: is not cited in the text. I would also include a symbol/shading/feature to allude to ‘no-data for this time period’ ; it is not apparent to the reader when quickly glancing. Also include that missing data means lack of data in the caption.
Figure 2: why not plot as a difference? You could choose one as a ‘reference’ compute the difference from that.
Figure 3: ð¿18Oc-based temperature is plotted against combined Mg/Ca and Tex86 is there a difference between the ð¿18Oc-based temperature vs. Mg/Ca or vs. Tex86? For me age in the left plot is not needed so you could make the orange and blue Mg/Ca and Tex86 rather than LP and PETM.
-
AC1: 'Reply on RC1', Daniel Gaskell, 07 Feb 2023
We thank Dr. Metcalfe for these very positive and constructive comments. We agree with essentially all of these suggestions, and the majority are straightforward to implement, so we will revise the code and manuscript accordingly if selected for revision and publication. Additional comments on specific points are below.
> "Line 29: 'less reliable' I would be less diplomatic 'next to impossible compared with'"
We are more inclined to be diplomatic, as a number of recent papers have shown good success at using d18O for SST measurements (Gaskell et al. 2022 PNAS; de Vleeschouwer et al. 2019 Clim. Past; etc.). However, this remains a topic of debate in the proxy community, and we hope that by improving the accessibility of the best available methods, our tool will help to further clarify the issue.
> "Line 104: (also line 73-74) latitude is constant but longitude changes distance, how is this accounted for?"
This method behaves as described in Gaskell et al. (2022) PNAS, which our implementation replicates. The reviewer is correct that the dimensions of the patch do not remain constant across all latitudes; in the revised version of the tool we plan to also include an option to calculate patches by great-circle distance, as is currently done for the nearest-point option.
> "Figure 2: why not plot as a difference? You could choose one as a ‘reference’ compute the difference from that."
We have chosen to plot absolute temperatures rather than differences so the reader can see whether the performance of different methods is sensitive to absolute temperature. (The absolute temperatures of each time/site are also of broader scientific interest.)
Citation: https://doi.org/10.5194/cp-2022-74-AC1
-
AC1: 'Reply on RC1', Daniel Gaskell, 07 Feb 2023
-
RC2: 'Comment on cp-2022-74', Anonymous Referee #2, 09 Jan 2023
Gaskell and Hull present a useful online tool that allows to “play” with different d18O temperature conversions and correction procedures. I think this is a convenient way to evaluate the impact of these different procedures on oxygen isotope datasets. In addition to the tool they also aim to demonstrate that common approaches lead to temperature underestimations in the the North Atlantic and overestimates in the Southern Ocean during hothouse climates.
The tool works smoothly and generates a nicely organised output. It would be great if several options could be selected at the same time to allow quick direct comparison of the effect of different options. While this would be a nice addition I would not say it is a must have.
In the conclusion I would suggest to not to focus on the latitude effect alone but instead summarise the various effects that different correction steps/assumptions on oxygen isotope derived temperatures have in general. “Ground-truthing” any d18O derived temperatures with either Mg/Ca and or TEX86 is not fully appropriate as both of these proxies have their own uncertainties, require assumptions and have complications. If done it would require a thorough discussion of these as well. I think the comments on the North Atlantic specifically could be omitted and would be better placed in a separate article and not necessarily in the presentation of this tool. I would therefore also suggest to exclude the part on the North Atlantic and Southern Ocean (line 12-16) from the abstract.
Line 25: Sharp 2017 is not an appropriate reference here.
Line 27: The introduction gives a nice overview, however I am missing references to highly relevant new insights from clumped isotope thermometry that can be used in addition to classic d18O measurements. E.g. Clumped isotope estimates challenge the simple conversion of deep-sea oxygen isotopes to temperature (see discussions in Agterhuis et al. 2022 and Meckler et al., 2022).
Line 31-41: What about uncertainties in seasonally variable d18Ow (associated with often unknown/uncertain calcification season of the planktic foraminifera)
line 69: specify where the local d18Osw data is derived from (Tierney 2020 model output?)
line 71: for the bottom water temperature it would be again to include the results of Meckler et al. here as well
line 82: in the tool, it would be nice to see immediately what the different options for the ’s’ values are
line 97: Meckler et al. derive different d18O sw values using clumped isotopes, would be useful to include these values also in the tool but also use it in this example
line 97-98: for the purpose of this article demonstrating the tool it would be nice to show in the example what the potential effect is of carbonate ion effect on final temperatures
line 132-140: In the conclusion I would suggest to avoid focussing here on the latitude but instead summarise and highlight the large variability that can derive from using different assumptions in oxygen isotope thermometry
Citation: https://doi.org/10.5194/cp-2022-74-RC2 -
AC2: 'Reply on RC2', Daniel Gaskell, 07 Feb 2023
We thank the anonymous reviewer for their very positive and constructive comments. The majority of these are straightforward and will be adopted as suggested if the manuscript is selected for revision and publication; comments on other specific feedback are given below.
> "It would be great if several options could be selected at the same time to allow quick direct comparison of the effect of different options."
This is a common request, but probably something we will leave for a future version as it involves several technical challenges (e.g., maximum PHP runtime defined by the server) and would substantially increase the complexity of the interface for a relatively small gain in usability. At present, results can be compared manually by the user.
> "“Ground-truthing” any d18O derived temperatures with either Mg/Ca and or TEX86 is not fully appropriate as both of these proxies have their own uncertainties, require assumptions and have complications."
The reviewer is correct that Mg/Ca and TEX86 have their own uncertainties, so they should not be treated as an accurate baseline against which d18O-based temperatures can be compared. Our intent for Figure 3 was to visualize how different methods can improve or worsen inter-proxy agreement; we will revise this section to clarify this.
> Line 31-41: What about uncertainties in seasonally variable d18Ow (associated with often unknown/uncertain calcification season of the planktic foraminifera)
Seasonal variation in surface d18Osw has generally been omitted from most published temperature-conversion methods. This is largely because seasonal variations in d18Osw are typically small compared with seasonal variations in temperature, which in turn are convolved with seasonal variations in foram abundances, making seasonality of d18Osw a relatively minor component of the overall uncertainty. Calibrations such as bayfox are constructed by comparing annually-averaged forams (such as core tops) to annually-averaged d18Osw (such as that estimated by LeGrande & Schmidt 2006, Tierney et al. 2020, etc.), which avoids the problem altogether by implicitly baking seasonal variations in surface d18Osw into the calibration equation and its corresponding uncertainty bounds. A full treatment of this issue is probably beyond the scope of this Report, which focuses on implementing existing methods rather than developing new ones, but we would be happy to include a brief discussion of this in the next draft.
We wish to thank the reviewer for drawing our attention to the newly-published d18Osw estimates in Meckler et al. (2022), which are exactly the type of relevant input datasets we hope to continue to add as options in this tool.
Citation: https://doi.org/10.5194/cp-2022-74-AC2
-
AC2: 'Reply on RC2', Daniel Gaskell, 07 Feb 2023
Daniel E. Gaskell and Pincelli M. Hull
Model code and software
Source code for converter tool Daniel E. Gaskell, Pincelli M. Hull https://github.com/danielgaskell/d18Oconverter
Daniel E. Gaskell and Pincelli M. Hull
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 484 | 187 | 18 | 689 | 10 | 10 |
- HTML: 484
- PDF: 187
- XML: 18
- Total: 689
- BibTeX: 10
- EndNote: 10
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1