Hi! I’ve been exploring the outputs of the SDR model and I want to check whether my understanding is correct.
I’m working at the watershed scale, and my assumption is that if I sum all pixel values from the E’ layer (e_prime.tif), this total should match the sum of all pixel values in the sediment deposition layer (sed_deposition.tif). In other words, I expected the total amount of sediments that do not reach the stream (E’) to equal the total amount that ends up being deposited within the watershed.
Is this assumption correct?
When I perform this calculation, the sums don’t match. In fact, for all the watersheds I’ve tested, the total E’ is consistently higher than the total sediment deposition. I’m trying to figure out whether this difference is expected based on how the model works (and I might be misunderstanding something) or there might be an error in my processing.
Could someone help clarify whether these two layers should, in principle, add up to the same total? And if not, why might E’ typically be larger than sediment deposition?
Hi! I wanted to follow up on my previous post above with some additional findings after further testing of the SDR model.
While re-running and closely inspecting outputs, I noticed something unexpected that might help explain part of the discrepancy I described earlier between total E’ (e_prime.tif) and total sediment deposition (sed_deposition.tif): even when using the Sample Data provided by the NatCap, I observed that the sediment deposition layer contains non-zero values in pixels that are classified as streams. That is, in locations where the model identifies streams according to streams.tif, the sed_deposition.tif raster still shows sediment deposition values. Conceptually, this was surprising to me, since my understanding is that sediment deposition (or trapping) should occur before sediments reach the streams. Because of this, I am wondering whether this behavior reflects:
an expected aspect of the SDR model implementation that I may be misunderstanding, or
a potential issue in how sediment deposition is being computed or routed internally.
To explore this further, I tried reproducing the sediment trapping calculation outside the main InVEST workbench. In this external implementation, before running the deposition algorithm, I explicitly set flow direction values to zero in pixels already identified as streams. Doing this eliminated sediment deposition values within stream pixels, which seems more consistent with the conceptual model.
However, even after this correction, I still find that the total sum of E’ remains larger than the total sediment deposition. This makes me suspect that there may also be other contributing factors, such as:
some pixels not being treated as true high-point pixels in the routing logic, or
other edge cases in how contributing areas or flow paths are defined.
So, any insights, confirmations, or pointers to relevant documentation or code sections would be greatly appreciated.
Thanks for the post and really getting into some of the details related to SDR. I reached out to some NatCap SDR experts and they unfortunately can’t take a proper look at this currently. There are good software implementation questions in here as well and I wonder if @esoth might be able to weigh in on some of the routing questions. We’ve got this pinned for us to review further, sorry we can’t get to it immediately!
Short answer: It’s not surprising to me that sediment_deposition.tif shows positive values in streams because it takes into account sediment trapped upslope along the flow path, not just on the individual pixel. And I would not expect E’ to equal total sediment deposition, because these results are calculated in very different ways.
There might be some confusion around the difference between T and dT as described in the user guide. sediment_deposition.tif corresponds to T, not dT (there is no dT raster produced by the model, it is an intermediate value in the calculation of T). As defined in equation 83, T is “the amount of sediment flux that is retained on any pixel in the flowpath using dT as a weighted flow of upslope flux”. In other words, T is defined recursively in terms of the upslope pixels. There is no special case in the definition of T that requires it to be 0 on streams, and mathematically I would not expect it to be 0 given the model equations.
As far as E’, yes, at first it would seem that E’ (the sediment that does not reach the stream) might equal sediment deposition. But the model equations show that these results come from pretty different mathematical approaches.
E' is calculated pixelwise, i.e. for any pixel i, E'_i is calculated in terms of other variables from pixel i, and not in terms of the neighboring pixels. This approach accounts for the broader landscape of the watershed by factoring in D_{up} and D_{dn} (upslope area and downslope distance to stream, weighted by landcover factors). This approach is described pretty thoroughly in one of the SDR references (Borselli et al 2008, Prolegomena to sediment and flow connectivity in the landscape: A GIS and field numerical assessment).
Sediment deposition (T) is calculated using a more complex algorithm that involves hydrological routing over the landscape. T_i is defined recursively in terms of the neighboring pixel(s) that drain into i and that i drains into. T_i factors in E'_i, I suppose representing the transported sediment that arises from pixel i. But these are fundamentally two different variables and the model equations would not lead to them being equal.
I can’t speak to whether this makes sense intutitively - these variables represent pretty abstract concepts, so hopefully we can get a hydrology expert to weigh in. But I can attest that the code is doing what the user guide describes.
Thank you both for your thoughtful responses. they really helped me think more carefully about what might be happening.
After some additional investigation, I believe I may now better understand part of the behavior. Based on the user guide, one key property of the model is that "all non-exporting sediment flux on a boundary stream pixel is retained by that pixel” (Property B). My understanding is that this would only fully hold if the SDR value at stream pixels were equal to 1 (which is something that is also written in the user guide), which is something I’m not entirely sure is enforced in the model implementation. When I tested this outside of InVEST and manually set SDR = 1 for stream pixels, I found that the total E’ and total sediment deposition within a watershed became nearly equal (aside from small rounding differences). This makes me wonder whether this assumption could be influencing the differences I was observing.
Regarding the presence of deposition values in stream pixels, I think I now better understand this as well. Since SDR has an upper bound (commonly < 1, e.g., 0.8 as suggested in the guide), there will always be some fraction of E’ from pixels that drain directly to the stream that is not captured “anywhere”. That remaining fraction would then be “retained” at the first stream pixel, which explains why non-zero values appear there. So this seems to be an inherent feature of the model rather than an issue. This is my current interpretation. I may still be missing something, but the behavior is making more sense to me now.