Summary

SIPNET tracks wood carbon in two pieces:

structural wood = envi.plantWoodC
storage delta   = envi.plantWoodCStorageDelta
reported wood   = structural wood + storage delta

storage delta can be negative because it is a bookkeeping. But SIPNET does not clearly define or test what should happen when this storage term interacts with harvest, turnover, respiration, and output reporting.

Related:

• Negative live biomass should cause mortality or error #325
• ensureNonNegativeStocks clamps plantWoodC but not plantWoodCStorageDelta , sum can go negative and break downstream fluxes #324

Potential Issues

Harvest calculates affected wood using:

woodC = envi.plantWoodC + envi.plantWoodCStorageDelta;

but the event update applies the wood change only to:

envi.plantWoodC

and does not update envi.plantWoodCStorageDelta.

That means a full aboveground harvest can remove more wood than exists in the structural pool, after which structural wood is clamped to zero while positive storage remains. The result is that sipnet.out can still report positive plantWoodC after a harvest that appears intended to remove all aboveground wood.

Negative storage is allowed, but if:

envi.plantWoodC + envi.plantWoodCStorageDelta < 0

then wood respiration and wood turnover can become negative because they use this sum directly.

Suggested fix

Make the intended functionality explicit and add focused tests:

1. Decide whether harvest acts on structural wood, reported/effective wood, or both.
2. Prevent negative effective wood from creating negative respiration or turnover fluxes.
3. Update the output docs for plantWoodC and nppStorage.
4. Add tests for harvest with positive and negative storage.