-
Notifications
You must be signed in to change notification settings - Fork 92
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should some termination mortality be reported as carbon starvation mortality? #1095
Comments
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? |
@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., |
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... |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: