Events: revamp handling of "big delta" events to post-pool-update

Open
  • Is something wrong?
#423 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 2 days

@Alomir is already working on this.

Since Oct 27, 2026.

Assessment

This issue has not been assessed yet.

Description

We have issues dealing with events that can potentially cause significant deltas in pools, primarily those that can drive a pool to zero. (Forward Euler methods for first-order DEs typically cannot handle step function changes well). The amount of code we have to deal with the overshoots that these events can cause is a significant contributor of complexity in the model's compute-fluxes->update-pools->repeat paradigm.

Proposal: move handling of these events to a new post-pool-update step, where we can calculate changes based on the resulting pool sizes, and remove the risk of overshooting; limit their effects to the resources available. Process these delayed events in the order that they should get priority, on the off chance more than on is on the same day.

Events to be postponed, and the order to process them:

  1. leaf on
  2. harvest
  3. leaf off

Harvest is after leaf on so that we do not suddenly have a lot of leaves after a harvest occurs. Harvest is before leaf-off to reduce the amount of leaf-off litter that is produced after a harvest (reducing it to zero in the case of a terminating harvest). For that last one, the question is: if we have both on the same day, do we want to harvest the leaves, or let them go to the litter pool? This order says to harvest them.

Hopefully, significant complexity can be removed in checkMortality() and the functions in limitations.c; possibly other places.

Tests will need to be updated, especially those in tests/sipnet/test_system - likely others as well, though.

Dominant language
C
Stars
42
Forks
38
Avg merge
3d 21h
Merged PRs (30d)
10

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from PecanProject/sipnet

All issues in PecanProject/sipnet

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.