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.   

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