Review of „CYCLIM: a semi-automated cycle counting tool for palaeoclimate reconstruction” by Forman and Baldini. (egusphere-2025-3749)

In this paper the authors present a code, which is able to automatically count isotope-geochemical growth bands. The aim is to provide a fast method to perform the annual layer counting task to establish a precise chronology. While there have been some approaches of automated layer counted algorithms available in the field, the new aspect of their approach is to allow the user a refinement after the automated counting procedure. However, even the counting algorithm alone seems to perform quite well, when judging the results of the three provided examples, each of different complexity. With the authors approach, the user can perform the counting-task much faster than when counting all cycles alone.

The manuscript is well written and structured. Especially, the introduction appears to be very nice to me. I also liked the section with the examples and the short discussion. What could be somewhat improved is the methods part, which is the most important section in the manuscript. I miss a bit more details on the model parameters and their influence on the layer counting. Please find more details on my – what I would call – moderate suggestions listed below. Pending on improvements with respect to the suggestions, I suggest to consider this manuscript for publication in CP. To my opinion the manuscript deserves to be published as I can imagine, that many researchers can and will make use of this approach.

Kind regards.

#################################################################################

Minor to moderate comments/suggestions:

L14 and L311-312: The term ‘14.1 times faster’ is very specific. And unfortunately, it is not explained in the text, how this number is calculated. At the moment, I doubt this number. Especially, that this number is always – for all records no matter how difficult or long they are – 14.1. I suggest to change this, to something broader, something like: ‘one order of magnitude faster’.

L75-78: This part is about the parameters. Unfortunately, this part is relatively poor, to my opinion. It is not described at all, how the parameters are derived by the code. There is also no real description about what the parameters are and what they are steering or how they influence the result. In the results section, where the approach is tested against already published data, there is some text, which helps to at least adumbrate how some of the parameters are derived. I suggest to at least add a table where the necessary parameters are listed, where it is shortly explained how they are determined or what are typical values. Maybe it is also helpful to leave some sentences in the text or table, which describe them in more detail.

Interesting for the reader may also an answer to the question, what the choice of the mean cycle length has an influence on the result – at least for the automated part. –  I guess the total influence on the result is minor, as the manual part can change the result in an arbitrary way.

L78-79: What happens with gaps due to cuts of the samples as they might occur during sample preparation? Are they also covered by this?

L80-83: This is a very helpful tracking procedure. Very nice idea.

L84-85: You are counting possible types of anchor-points here – i.e. only one of each type. However, I can imagine, that especially for U-Th ages, there could exist more than one dated depth over the counted interval. Is CYCLIM able to cope with that as well? Including all (possible) U-Th dated depths (if available) in placing the counted interval could really help to pinpoint the chronology.

L85-86: “The algorithm derives a median age model from 2,000 Monte Carlo realisations using piecewise cubic Hermite interpolating polynomial (PCHIP) interpolation, which …” Can you please elaborate a bit more on this? I don’t understand why you are needing interpolation here. And what kind of Monte Carlo realisations? What is varying?

L 86: “uses” à “used”

L88-L89: “Furthermore, CYCLIM can translate the proxy values onto a time-certain axis to convert age uncertainty into proxy uncertainty.”  This is not a specific comment to this paper, and you are free to ignore, if you like, but maybe you can help me out here.

I know this concept has already been proposed in earlier studies (e.g., Breitenbach et al., 2012). However, I, personally, do not really understand this concept. It appears not to be meaningful to me. I always think about this the following way: Only as a signal cannot be put perfectly in time, the magnitude of an event is not smaller than measured. Or more extreme, only as a clearly pronounced event in the measured proxy cannot be dated at all, it does not mean it is not there at all, as this approach would tend to suggest. At least this is my argument for not agreeing with this approach. But this is only my opinion about this issue. Maybe there are arguments in favour of this procedure, I am not aware of.

So, my question to this sentence would be, if this feature can be deselected by the user?

L103-106: Could you elaborate a bit more on the choice of the width, w? I think this would help the reader, to set their own w if they prefer to do so. What is the impact of a change in w? Can you perform a short sensitivity analysis? Maybe with one of your example data sets (or all).

Per default CYCLIM is using the half average annual cycle length. However, growth layers can change quite strongly throughout the record. What would happen to phases, where the cycles are much shorter than the average. And what would happen to phases, where there is very rapid growth? Does such a behavior result in an under- or over-counting. I think, this would be very interesting to the reader. At least to me, it is.  

Related to this, it might be worth in another, future version of CYCLIM to make the template width, w, depth adaptive by using a wavelet. In case the over- and undercounting in periods with low and high growth rates is an issue, this method could improve the counting performance, when changes from fast to slow growth occur. Just an idea.

L119-221: “minimum prominence criterion” Please elaborate more on this. What is this? How did you (or CYCLIM) is defining this? Have you tested the impact of this criterion? Is this the same as what you are later, in sections 3.2.1 to 3.2.3, are setting to 0.04 permil (Houtman Abrolhos Coral), 2.5% (C09-2), 503 ppm (BER-SWI-13). You may be able to test the impact of this value with these or at least with one of these data set. Just to give the reader an idea on the sensibility of the parameter choice. Thus, I suggest to elaborate a bit more on this value. Just to find the impact with respect to the identified cycles. Just use the same time series, with a value equivalent to 1, 2.5, 5 and 10 % of the range in y (or other values) and look for changes in the result. Maybe the results will be different with a change in the growth rate, proxy amplitude or signal to noise ratio of the smoothed record.

But then again, as the approach is semi-automatic, the user can correct anything the program found too much or too less. This should be also mentioned, when doing the sensitivity analysis.

Fig. 2: I suggest to put the red line on its own y-axis (right hand side?). Otherwise it is confusing with respect to equation 1.

Section 2.3: I agree, that this is an option to try to estimate the uncertainty. But to me it reads rather as an unusual one, as it is not the time series/signal, which is uncertain. It is the counting through the choice of the parameter set.

Therefore, I would have tried to randomly change the configuration of parameter set, the user is free to choose (or the default values). At least within a certain environment.

In this way, the signal remains as measured, as it is most likely not the signal, which is loaded with uncertainty, but rather the choice of parameter values.

I know, I would ask much, if I would request to chance the uncertainty algorithm. Probably, this would require some (heavy?) recoding. Therefore please, decide for yourself, how you like to proceed. In any way, I also provide a few thoughts on the present algorithm.

L142: “For multiple random seeds … in 1% increments (from 1% to 100%).” For how many multiple random seeds? Does this mean you tried e.g. 1000 random seeds and increased the white noise from 1 to 100% for each random seeds in a way that you get some statistics for your F1 approach? Please also elaborate on, what the '%' unit means in this relation. I have no idea.

L145: “that are true”. What is meant by this? 'True' as in 'with respect to what was found in the undisturbed signal' (which does not mean that it is really true)?

Fig. 3d and Line 175-176:  I understand your argument for the stepped nature of the error estimation. I also understand, that the way the age uncertainty is calculated, floating values are produced. But to my understanding the 'deviation from mean model years' can only be integer values. Either one identified minimum counts or does not count. Is it an option to at least round the values?

Fig. 7c (same in Figs 9c and 11c).: about the “temporal offset”. How can the offset be floating values? I don't understand this. Please explain. To me, showing the floating values suggest that it is possible to differentiate seasons! Is that intended?

Fig. 8 (same in 10 and 12): At least for a) the quality of the figure must be improved to see the differences, when someone is zooming in to see the differences in the ages. In the present manuscript version the resolution is too poor. Maybe use vector graphics?

Line 313: “other method” Please name this other method. Is this method mentioned in the methods-section? I can't find it.

Review of the manuscript “CYCLIM: a semi-automated cycle counting tool for palaeoclimate reconstruction” by Forman and Baldini, submitted to Climate of the Past

General comment:

Forman and Baldini present a new algorithm/software for automated cycle counting. The intended application is to climate archives, such as sediments, ice cores or speleothems, but it seems that it could also be used in other research fields. The software allows the user to manually optimise the counting once the automated output is available, which is an advantage to previous algorithms, which – as far as I know – didn’t offer such a feature directly in the software. I also really like that the software tries to automatically assess the uncertainty of the counting using a Monte Carlo approach.

The paper is interesting and well written, and I recommend publication in CP after minor to moderate revision. I have two general comments that should be addressed in a revised version. (i) It is not entirely clear to me how the uncertainty of the combined output (i.e., the automated and manually corrected counting) is calculated. Is the uncertainty of the automated output just ignored after ‘tuning’ because the manually obtained result is assumed to be both more precise and accurate than the automated output? Is the uncertainty of the automated output propagated to the uncertainty of the combined output? Does the algorithm inform the user if the manual tuning would require adjusting the automated counting far more than suggested by the uncertainty (i.e., the automated counting has an uncertainty of 10 years, but the used wants to add 50 ‘missing’ years)? This should be clarified and included in more detail in the discussion. (ii) I would also like to see a more detailed discussion of the uncertainty of automated vs. manual layer/cycle counting chronologies in general. I know that this is also kind of a philosophical question, but the authors mention by themselves that their algorithm provides an ‘objective’ way to determine counting chronologies and the corresponding uncertainty. Even if I agree that expert knowledge of the corresponding climate archive will help to improve the automated counting chronologies, these are at the same time always affected by some degree of subjectivity. In the worst case, the user already ‘knows’ where a specific peak in their proxy time series should occur (e.g., at the 8.2 ka event, at the YD, etc.) and may get the impression during counting that they count too many/not enough cycles. Thus, I would really like to see an extended discussion of the pros and cons of automated vs. manual counting, the potential effects of subjectivity and how to deal with the corresponding uncertainty. In other words, what is better? An automated counting chronology with an uncertainty of 10 years, or a manually refined chronology with a lower uncertainty (however this was determined, see my first comment) that is potentially affected by the subjectivity of the person doing the counting/tuning.

Detailed comments:

Title: As mentioned in my general comment, the algorithm could in principle not only be used for climate reconstruction. Thus, I would delete ‘for palaeoclimate reconstruction’ from the title. If the authors prefer to keep the reference to palaeoclimate, I would use ‘climate archives’ instead.

Line 66: ‘By facilitating both efficiency and supervision, CYCLIM enhances the speed, accuracy, and transparency of cycle counting.’ Even if I generally agree, I really would like to see a more detailed discussion of the potential uncertainties of automated vs. manual counting (in particular in terms of subjectivity) and how to combine them (see my general comment).

Section 2.1: This section gives a useful overview of the software, but when I read it, I immediately had many questions (e.g., about the calculation of the uncertainty). Thus, I would suggest removing all references to the technical aspects (e.g., that ‘the algorithm derives a median age model from 2,000 Monte Carlo realisations using piecewise cubic Hermite interpolating polynomial (PCHIP) interpolation …’) and just describe the structure of the algorithm here.

Line 128: ‘To maintain accuracy and avoid undercounting, …’ I guess this paragraph describes the ‘gap treatment’ referred to elsewhere in the manuscript. Even if I think that I understand what the algorithm does here, it may be good to demonstrate this showing an (maybe artificial) example. This would be very helpful for the reader to understand the functionality of the algorithm.

Line 188: ‘… and low noise level (Fig. 3).’ Here and elsewhere in the paper, please check the numbering of the figures. It seems that this should be Fig. 4.

Fig. 5: I didn’t find a reference to Fig. 5 in the text.

Line 232: ‘The automatic age model achieves a good match with that published by Kuhnert et al. (1999), albeit with clear signs of overcounting (Fig. 7a and c).’ In the light of my general comment regarding the pros and cons of automated and manual counting, why should the published chronology be better than the automated counting? I am sure there are very good reasons for this assumption, but they should be mentioned and discussed in the manuscript.

Line 233: ‘The overcount increases with depth to a maximum of 8.05 years (mean absolute error = 4.56 years, 2.3% of the target’s temporal range), …’ I am not sure that I completely understand the meaning of the ‘mean absolute error’. Is this the mean deviation from the mean model at the bottom of the chronology shown in Fig. 3? What would be the corresponding 95%-confidence interval at the bottom of the chronology? Are these limits always symmetric (i.e., is the probability for over and undercounting always comparable)? This information is essential to assess the performance of the algorithm. If the maximum uncertainty (at the 95%-level) is 4.5 years, then an overcount of 8 years would be inaccurate.

Line 258: ‘This leads the record to have an accumulating mismatch which rises to a maximum of 8.23 years by the end of the record at 207 years counted (mean absolute error = 6.08 years, 2.8% of the targets temporal range).’ Same question here. What does the error mean? Later, it is said that 12 cycles were added in the tuning stage. This is more than the uncertainty of 6 years. Does this mean that the initial automated counting was inaccurate?

Line 266: ‘At maximum depth, the 95% algorithmic uncertainty is approximately ±2 years compared to the published ±3 years.’ How can the uncertainty of the tuned output be so much smaller than that of the initial automated output if 12 years were added. Are these assumed to absolutely certain even if the algorithm did not identify them? This also refers to my first general question regarding the treatment of the combined errors after tuning.

Section 3.2.3: Again, please provide a more detailed description of the different uncertainties mentioned in the text and how they were determined (in particular after tuning).

Line 308: ‘The CYCLIM algorithm extracts cyclicity information from three examples both accurately and quickly via an automated matched filtering technique, …’ Does this mean that the automated chronologies were accurate within their uncertainties? This did not seem to be the case to me, but maybe I misunderstood the quoted uncertainties (see my comments above).

Line 320: ‘The results from this stage follow the original chronologies very closely and further running could yield a perfect match.’ This again somehow suggests that the published chronologies were somehow perfect. Why should this be the case? Couldn’t it be that the chronologies determined here with the (less subjective) semi-automated method are more accurate?

Line 327: ‘(1) reporting an objective cycle count (i.e., the algorithm output) before correction; …’ This is exactly what I consider as one of the greatest advantages of the algorithm. Thus, it is very important to better describe how the uncertainty of these ‘objective’ cycle counts are afterwards propagated to the final ‘tuned’ result. Who can guarantee that the user does not add ‘false’ cycles or delete ‘true’ cycles?

Section 5 (conclusions): This section rather reads like an abstract than conclusions. I would completely delete the 1^st paragraph and focus on the results here.