Skip to content

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

Closed
JessicaNeedham opened this issue Oct 10, 2023 · 6 comments
Labels
history output Pertaining to FATES history output variables

Comments

@JessicaNeedham
Copy link
Contributor

JessicaNeedham commented Oct 10, 2023

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.

@JessicaNeedham JessicaNeedham added the history output Pertaining to FATES history output variables label Oct 10, 2023
@rosiealice
Copy link
Contributor

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?

@mpaiao
Copy link
Contributor

mpaiao commented Oct 11, 2023

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.

@JessicaNeedham
Copy link
Contributor Author

@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?

@JessicaNeedham
Copy link
Contributor Author

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?

@mpaiao
Copy link
Contributor

mpaiao commented Oct 12, 2023

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...

@rosiealice
Copy link
Contributor

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...

@NGEET NGEET locked and limited conversation to collaborators Oct 16, 2023
@glemieux glemieux converted this issue into discussion #1100 Oct 16, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
history output Pertaining to FATES history output variables
Projects
Archived in project
Development

No branches or pull requests

3 participants