Insufficient carbon for growth should cause mortality, and fix C balance

[dlebauer]

Problem

SIPNET can generate negative values of biomass. When biomass <0, plants should die.

In the current code, impossible negative states biomass pools are repaired after they are updated by clamping stocks to zero rather than handling plant carbon-deficit failure explicitly.

However, when plantWoodCStorageDelta term added to the wood update, it is possible for aboveground biomass to be negative at the end of the time step (and thus, in the sipnet.out).

Related but out of scope:
If the clamping is > tolerance, the ensureNonNegative function warns but still clamps to 0. It seems this could introduce phantom mass.

Proposed change

Implement a mortality rule:

• do not allow live structural biomass pools (wood, leaf, fine root, root) to go negative (current clamping behavior)
• do not let negative wood storage make wood-based fluxes or biomass outputs negative
• trigger mortality before stock clamping if a timestep would drive any live structural biomass pool negative
• on mortality, set plantWoodC, plantLeafC, fineRootC, coarseRootC, and plantWoodCStorageDelta to zero in the same timestep
• transfer the biomass of the dead plants as currently implemented:
  • roots --> soil
  • leaves and wood --> litter if litter-pool=on, otherwise --> soil
• if plantWoodCStorageDelta is negative at death, remove that from the amount transferred to litter / soil
• do not rely on clampedC / clampedN in the mortality path

Acceptance criteria

• No live structural biomass pool < -eps [eps = small tolerance].
• Carbon-deficit triggers explicit mortality instead of clamp-based repair.
• Mortality conserves mass and uses current aboveground/belowground routing conventions.
• If wood storage is negative at death, mortality routing does not create phantom carbon. I can't think of anything simpler than mass balance is maintained by taking from other pools either evenly or in order: wood, root, [leaf + fine root])

Alternatives

After looking into this, I realized how complex it is to represent mortality! In croplands especially, mortality is not a high priority. If it is simpler to throw an error, lets tag this issue 'on hold' and just do that.

Related

• ensureNonNegativeStocks clamps plantWoodC but not plantWoodCStorageDelta , sum can go negative and break downstream fluxes #324 may be resolved by the fix here
• Account for stock clamping in mass balance check #282
• SIP208, SIP209 Add carbon balance check #248

[dlebauer]

During today's meeting, @Alomir confirmed that while this is a realistic and appropriate scheme, it is certain to be more complex than is implied by 'if biomass is negative, plants die following t_n+1 = max(0,t_n + flux*dt)

He also made a good point that the current behavior is largely a consequence of a recent fix that invalidated existing parameterizations and is thus primarily a calibration problem.

Thus, it seems prudent to recalibrate first so we’re working with reasonable parameters before treating this as a blocker that must be fixed now rather than as a new feature that can be implemented down the road.

I would prefer that SIPNET not generate negative biomass, but also realize that it isn’t practical to defend against every way the model can be mis‑parameterized or misused. In the context of SIPNETs simple representation of California croplands, persistent negative biomass can be treated as a calibration failure.

[mdietze]

While I'm willing to accept this isn't the top priority, I disagree with the assertion that a model capable of producing negative biomass is a "calibration issue". The ability to produce physically impossible values is a structural issue that does eventually need to be fixed

[Alomir]

I agree that there is a design issue here, though I won't comment on the priority of fixing it.

Other thoughts: the C storage pool is a real conundrum. It's not really wood C, that's just where sipnet has classically placed it. On the one hand, I wonder if the above-ground check for death should be (wood C + leaf C + storage C) < -eps, but that can lead to reporting negative total wood C. (I'm thinking about very young plants that are mostly leaves - or is that not a thing?)

Similarly, on the reporting side, I wonder if, when wood C + storage C is negative, we should report it as zero and reduce leaf C by that excess amount (and if that makes leaf C negative, we're in the realm of the check above).

[dlebauer]

@mdietze I agree this is a structural issue. The "calibration failure" framing was too it was more of 'lets determine whether this issue occurs under a reasonable parameterization before bumping it to higher priority.

But I think that we've gotten to a point where mortality is looking like the clear solution.

I have been looking into the literature on how models implement mortality as a function of nonstructural carbohydrates and trying to map that to something simple and sufficient for SIPNET.

But there is an underlying issue that we have to solve before this will work: instantaneous leaf-on creates a large one-day C and N demand. It would be difficult to keep the feature of being able to take an arbitrary amount of wood C and put it in leaf C. This instant demand basically requires there be enough C and N to support it, or else it can cause negative biomass and N limitation.

So before implementing mortality, I think we should write down the equations and clarify what leaf-on is allowed to do. The code required to support large leaf on events (that were previously partly subsidized by the double-counting wood creation bug, and not N limited) is not straightforward to support.

For now, I’d favor removing conditions that violate mass balance and erroring if mass balance is violated. So, next steps are to determine what leaf on and storage mean and are allowed to do so that leaf on doesn't kill the tree and fluxes can go in reverse (e.g. a harvest that transfers litter to plant biomass), and what a simple path to mortality would look like.

[dlebauer]

@Alomir I agree storage hard! I would avoid reporting woodC + storageC as zero by subtracting the deficit from leaf C, because that turns leaves into another bookkeeping abstraction that is not biologically realistic. Near-term: fail loudly on physically impossible states - or at least expose them so that they can be assigned zero probability in calibration. Longer-term (I'll have time next week to start writing this out): design a storage based mortality rule that routes biomass to litter/soil.

[mdietze]

First, I wouldn't make mortality overly complicated. As suggested before I'd start with a simple absorbing boundary at 0 -- pool[t+1] = max(0,pool[t] + flux*dt) or the equivalent achieved by checking each flux against it's potential (which would be the way that would ensure conservation). Either way, a plant is dead when all of its C pools are 0.

Next, if leaf out is what's pushing wood negative, then you cap that flux too leafout = min(leafGrowth,Cavail, (C:N)_leaf * Navail) where Cavail would be the carbon available for growth (e.g. storage + wood) and Navail would be similarly be C_wood/(C:N)_wood + N_storage. Up to y'all if you want to allow the additional complexity of allowing plants to nonphysically create leaves from roots too -- I'd lean against it. Note that the C:N ratio of the C storage pool is usually Inf -- if you have (or introduce) a N_storage pool it would serve a separate purpose.

I'd also be careful with any leaf senecense re-allocation scheme to not make it too complicated -- It may be valuable for pulling fraction of N back from leaves into N_storage (to be available for the next year's leaf out), but reallocation of structural leaf C is pretty low and probably simpler to ignore. I'm also nervous that including a N_storage and N reallocation is going to make the model sensitive to the relative timing of senecence vs harvest, which we haven't really parameterized into the harvest product (because at the time we designed it we hadn't planned for reallocation). Researching that relative timing is definitely post-MVP. That complexity may not be justified for annual crops, where adding N reallocation would just shift N into a virtual Nstorage pool that then immediately gets dumped into the litter, same as it would have without N reallocation. For our deciduous trees, leaves shouldn't be harvested and leaf litter associated with harvest shouldn't be huge.

[infotroph]

One piece we discussed live the other day that I don't yet see captured above: We should make sure the leafout rule makes sense in immature plants. Right now we have saplings trying to add a mature tree's worth of leaves in a single timestep; @mdietze's Cavail suggestion would alleviate that but I wonder if we'll need to make less than 100% of wood be "available" to let small plants climb out of the growth trap.

[infotroph]

Either way, a plant is dead when all of its C pools are 0

Does this allow a way to simulate tree death that leaves behind coarse woody debris?

[dlebauer]

Does this allow a way to simulate tree death that leaves behind coarse woody debris?

I need to update the issue title and description, but I've been looking at how other models do this using the storage/nsc pool and plan to use that path. I agree, dissolving into nothingness isn't a reasonable way to die.