Comment on gchron-2021-39

-The authors motivate this work by pointing out that landscape evolution and sediment transport modeling projects tend to completely avoid most aspects of sediment accumulation. Of course avoiding this is sensible in lots of applications, because if you have a 2-d landscape evolution model, once you start accounting for a sediment pile that is not perfectly mixed, then you have to add an additional dimension, but only in some of the model cells, etc. But it is true that this is a limitation in a lot of applications, for example in simulating cosmogenic-nuclide concentrations in fluvial sediments leaving a basin that contains both eroding and accreting areas. So I am very supportive of putting some effort into this area.


Broader comments:
--Note: I should not be trusted as having adequately reviewed the R code. I rarely use R.
--The authors motivate this work by pointing out that landscape evolution and sediment transport modeling projects tend to completely avoid most aspects of sediment accumulation. Of course avoiding this is sensible in lots of applications, because if you have a 2-d landscape evolution model, once you start accounting for a sediment pile that is not perfectly mixed, then you have to add an additional dimension, but only in some of the model cells, etc. But it is true that this is a limitation in a lot of applications, for example in simulating cosmogenic-nuclide concentrations in fluvial sediments leaving a basin that contains both eroding and accreting areas. So I am very supportive of putting some effort into this area.
--I agree with the other reviewer that this is a lot of software, and a lot of paper text, for a fairly underwhelming set of example applications. However, I can think of lots of other theoretical potential applications. In my own field, this could interestingly be applied to the issue of grain-size dependence of cosmic-ray-produced or fallout radionuclides in sediment, which produces results that are biased by sample preparation or grain-size selection. If you imagine trying to simulate this in a landscape evolution model for a watershed, one would have time steps in which packages of sediment with certain properties were deposited, and then later time steps in which packages of sediment were eroded in different increments, such that an eroded increment was a mixture of different previously deposited increments. The software described here is not directly designed for this application, obviously, but it thinks about the problem in a relevant way. Thus, I don't think the fact that the worked examples are fairly simple is necessarily a problem for the paper. I think it is OK, in fact, probably good, to present what one thinks is a fairly versatile tool even if one is not completely sure what to do with it.
--Although it is true that this is basically a mixing model for sediment properties that don't necessarily have anything to do with geochronology per se, it is clear from the OSL example, and the fact that I immediately thought of another example having to do with cosmogenic-nuclide applications, that this is likely to be at least somewhat interesting for geochronologists. I can think of general examples in other areas of geochronology as well, for example having to do with paleomagnetism of sediments or bulk radiocarbon dating. So this may be a little off topic for Geochronology, but I think it is OK.
--One general issue in reviewing papers about software is that really the point of the review is just to ensure that the paper is a good description of the software. Of course, all reviewers have a strong desire to suggest additional features of the software, or to complain that their favorite features are not included. However, it is not really a reasonable review criticism to demand that the software do things that the authors were not intending to do. From this perspective, I found the paper to be good. Even though I don't think in R, the paper fairly clearly describes how the software works and it is possible to get a good idea of its capabilities. I do agree with the other reviewer that some aspects of the introductory text (before the code examples) are longer than necessary and hard to understand. In this section, the authors describe the software design in very general and symbolic terms ("sandbox has a parametric and probabilistic design"...the paragraph near line 80 is particularly difficult) that are very hard to understand before the examples. Once the authors get to the examples, many of these points become immediately clear, which makes the introductory text appear more confusing. I strongly suggest that the authors remove some of this general introductory material and, perhaps, replace it with a simpler and clearer statement of the input and output parameters of the software ("Input parameters to the software are a set of properties, including the age, contributions of certain grain size components, etc. that are assumed to vary with depth in the section. The outputs are...."). Alternatively, the authors could start with the examples and then later explain how the example applications are special cases of more general design properties. At present, I am worried that many readers may not make it through the more abstract descriptions at the beginning. I became much more interested in the paper when I got to section 3, but if I were not reviewing it I might not have gotten there.
There are, however, two missing aspects of the software that I think are important to discuss in the context of possible geological applications. The first has to do with age models. The other reviewer alluded to this in pointing out that failing to allow for correlation between various properties of a sediment section is oversimplified in relation to real life. I agree with this, but am more concerned about oversimplification of the age model. The assumption that the age model is linear between specified (age,depth) points is quite important in many applications in which one might want to know the properties of a large sample that spans a range of ages. In reality, sediment accumulation is not expected to be linear, but rather episodic and commonly autoregressive. Thus, expected internal variability in accumulation rates would significantly change, e.g., the distribution of OSL grain ages in a thick sample. As the software is designed, it appears that it would only be possible to simulate this effect by generating a large number of age-depth models with additional synthetic age/depth pairs between the known ones, that had been generated to have whatever autoregressive (or not) properties that you want, and repeatedly generating and sampling synthetic sections for each one of the age models. I suppose, therefore, that the software doesn't really oversimplify this aspect --it just leaves it as an exercise for the student --but I think it would be helpful to have some discussion of this issue in the paper.
The second issue also to some extent echoes the other reviewer's point that there is no consideration of correlation between parameters, but the way I would express this is instead to point out that these correlations are often the result of physical relationships that must be honored for the synthetic sediment section to be a correct representation of the real one. The main example that stood out to me is that it appears that grain size distributions and density are set independently. In real life, on the other hand, for dry sandy sediments that typically achieve their closest possible packing at or immediately after deposition, the density is fully physically determined by the grain size distribution, so density is a completely dependent variable. A more poorly sorted sediment with a larger range of grain sizes always has a higher density (and also higher bulk strength properties...this is why a material with a larger range of grain sizes is called 'poorly sorted' in geology but 'well sorted' in civil engineering). I am not really an expert on this, but I do know that there is quite a lot of engineering literature relating grain size distribution to density, so it would be possible to incorporate a deterministic density calculation based on specified grain sizes. Again, this is getting pretty close to what I shouldn't be doing, which is to demand more features, but this aspect appears to me to be quite important as a potential reason that the synthetic sediment section might be a bad model for a real one.

Minor comments:
--The authors should critically read the paper with an eye toward removing jargon that is not in standard usage and/or more confusing than necessary. For example, "geo-archive" provides no more information, and more confusion, than "sediment section." Suggest removing it. Another example is 'paleo-research.' Also confusing: if the paleoenvironment is the environment that existed in the distant past, is 'paleo-research' likewise research that was carried out in the distant past?
--I suggest that the authors remove a couple of sections in which they become somewhat opinionated about the desired properties of geoscience software. For example, the remarks in line 45-50 are likely true, but are not at all relevant to the point of the paper. Perhaps the way to think about this is that facts about the software being described ("This software is written in a language that runs on all platforms") are certainly important and appropriate, but general opinions about what the authors think software should be like ("Ideally, such a model is transparent and flexible throughout...") are off topic and better suited to a proposal or opinion article. There is another example in line 59, which sounds like a TV advertisement for R.
--I didn't understand the sentence in 67-68. This seems to be an example of the general point above in which a very abstract description is very hard to follow before any examples are given.
--While looking at a black-and-white printed copy of Fig. 4, it occurred to me that this could just be presented as a contour map, which would be simpler, not require color, and not require a legend.