Closed JessicaNeedham closed 1 year ago
I agree this would be a more accurate description...
Why does it need to be tracked at the site level? Might that change if we added it on to then C starvation flux?
I agree that it makes sense to have it reported as part of carbon starvation mortality.
Though it makes me wonder if the carbon starvation mortality (sensu stricto) formulation should be a continuous function that goes to infinity when storage carbon approaches zero, as a way to avoid some step effect on mortality. But I think this is more a long-term discussion.
@rosiealice I think as it is now we'd need to track it at the site level because the cohort is eliminated, so we wouldn't be able to loop over it during history updates. But I guess what you're suggesting is that if we didn't actually terminate it here then that wouldn't be a problem in terms of accounting - we'd be able to track it along with existing c starve mortality? Is there a reason we don't already do that? Does having zero carbon storage mess up daily allocation or something?
I agree that it makes sense to have it reported as part of carbon starvation mortality.
Though it makes me wonder if the carbon starvation mortality (sensu stricto) formulation should be a continuous function that goes to infinity when storage carbon approaches zero, as a way to avoid some step effect on mortality. But I think this is more a long-term discussion.
@mpaiao - want to make sure I completely follow. Do you mean make the cstarve_scalar proportional to the ratio of storage to leaf biomass, to the point where if storage is zero the scalar would be 1?
I agree that it makes sense to have it reported as part of carbon starvation mortality. Though it makes me wonder if the carbon starvation mortality (sensu stricto) formulation should be a continuous function that goes to infinity when storage carbon approaches zero, as a way to avoid some step effect on mortality. But I think this is more a long-term discussion.
@mpaiao - want to make sure I completely follow. Do you mean make the cstarve_scalar proportional to the ratio of storage to leaf biomass, to the point where if storage is zero the scalar would be 1?
If I remember correctly, FATES uses the exponential rate (i.e., dN/dt = -m N
), so setting the scalar to 1 would reduce the population by ~63% in one year. Perhaps we could make that number more like 10, which would cause 99.995% of the population to die, and I guess at that point the termination mortality could eliminate anything that may remain. But I imagine that radically changing the scalar (to 1 or 10) will have other consequences...
I also think it is worth experimenting with such an idea to shift the balance away from termination mortality, which is really just a fix for the maths or not killing the dying cohorts fast enough. And that the maximum number of th@ scaler needs to be >>1 to nail the whole cohort.
But then we get into a situation where a temporary carbon deficit would be more catastrophic, (I.e, in a dry or cold season) and so there is probably a very interesting and important window of tolerance on this. The dynamics IRL are probably different between different mechanisms, as in, trees can hold out against c starvation for a while but not against hydraulic failure?
I feel like these mortality parameters might be one of the next frontiers, calibration wise...
In FATES, cohorts are terminated when storage carbon is less than a very small number (see here ) and this gets reported as termination mortality in history outputs. Should we actually be reporting this type of mortality as carbon starvation mortality? Currently, carbon starvation mortality is only reported as the mortality triggered when cohorts’ storage carbon is below target storage (based on target leaf carbon). Seems like complete depletion of storage carbon should also be carbon starvation mortality.
Because termination mortality has to be tracked at the site level, this might mean making another site level variable that is then added to the existing carbon starvation mortality in the history updates.
This has come up in discussions with @adamhb, @ckoven and @jenniferholm.