Skip to content

apply the computed plantStorageNInit default conditionally #4114

Open

Description

@divine7022

Follow-up to #4112

Description

#4112 sets plantStorageNInit to the nitrogen needed for one carbon limited leaf flush, computed from the initialized wood pool, so the first leafon event is not suppressed when the nitrogen cycle is on. Post merge @infotroph raised three points, collected here for follow-up:

  1. The computed value overwrites the template value unconditionally. Every other write in write.config.SIPNET applies only when a corresponding input is present (a PFT trait, or a variable in the initial conditions), so a value set deliberately in a parameter template, including an intentionally nitrogen limited starting condition, is silently replaced. The IC argument is currently the only way to supply an explicit value.

  2. The guard/comment are easy to misread. The guard if ("plantStorageNInit" %in% param[, 1]) distinguishes v2 templates from v1 templates, which have no such row, but the adjacent comment reads "If not supplied", which actually describes the IC fallback later in the block. The mismatch invites misreading.

  3. The added test builds an events file it does not need. write.config.SIPNET can exercise this behavior without one.

Proposed solution

One proposed approach is to apply the computed default only when the template value is 0, the non-viable default that motivated #4112. A nonzero template value would then be respected, while the IC value would retain precedence. The behavior should also be documented clearly, including how to request an exact value, including an intentional zero.

The exact intended semantics of an explicit zero should be confirmed as part of this follow-up.

Alternative considered

static template default matched to the existing Niwot specific template (plantWoodInit = 30000 g C m-2 gives plantStorageNInit = 5.04 g N m-2), with documentation that initial conditions overriding the wood pool must also supply a consistent storage N.

This is simpler, but a run that supplies a smaller wood pool through initial conditions without supplying N would receive surplus storage N. The computed value instead scales with the initialized carbon and C:N ratios.

Done when

  • The intended default/override semantics are agreed upon and implemented.
  • Deliberately supplied template values are not silently overwritten.
  • Explicit IC values retain the agreed precedence, including the behavior of an intentional zero.
  • The comment accurately describes the fallback behavior.
  • The test runs without an events file.
  • Documentation clearly describes the precedence and how to request an exact value.

Related PR: #4112
I would appreciate feedback on the proposed approach before implementation

Activity

  1. infotroph commented on Sep 16, 2026

    @infotroph
    Member

    Yes, I support setting plantStorageNInit = 5 in template.param and dropping any further special handling (even when it's set to zero ) out of write.config.

    a run that supplies a smaller wood pool through initial conditions without supplying N would receive surplus storage N

    This is an acceptable caveat in my book and isn't unique to storage N -- it's inherent to PEcAn.SIPNET's longstanding design choice to use only a single fallback template for all runs. For any parameter in the model, if the user doesn't update a parameter and its template.param value is far off from what's reasonable for the question at hand, that's on the user.

    The guard if ("plantStorageNInit" %in% param[, 1]) distinguishes v2 templates from v1 templates

    Might be worth writing this as if (caps$has_n_cycle) with a matching has_n_cycle = rev_str == "v2", inserted around line 115

  2. coder-Yash886 commented on Sep 17, 2026

    @coder-Yash886

    @infotroph @divine7022 @dlebauer I am looking to work on this issue please assign me this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions