[divine7022]

Description

This replaces the initial PFT filter with support for sensitivity analysis across SIPNET crop changes. site.pft still identifies the initial vegetation. Crops introduced later use their sampled parameters when active and remain
in the sensitivity results.

It also fixes baseline only manifests and selects constants for correct PFT, while preserving NULL defaults for existing callers. Direct run.write.configs calls accept one analysis at a time; combined SA and ensemble runs use runModule.run.write.configs.

Motivation and Context

Review Time Estimate

• Immediately
• Within one week
• When possible

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• My name is in the list of CITATION.cff
• I agree that PEcAn Project may distribute my contribution under any or all of
  • the same license as the existing code,
  • and/or the BSD 3-clause license.
• I have updated the CHANGELOG.md.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[infotroph]

Does SA support segmented runs? In the segmented case site.pft contains the initial PFT and others are activated in later segments using the PFT parameters passed here.

[infotroph]

I suspect one could make a design argument that from the run.write.configs perspective maybe site.pft should contain every PFT the site will use at any time in the run. But making it work that way would need a change in how write.config.SIPNET handles it and I'm not immediately sure how we'd mark the initially active PFT.

[infotroph]

@divine7022 gentle nudge about my question above -- seems important to get right before merging.

[divine7022]

Thanks Chris!. my recent SA runs were unsegmented, and I haven’t tested segmented SA. The current segmented writer expects ENS run IDs and ensemble.samples files, so I haven’t established working segmented SA path

I see your point about site.pft, for a segmented run it can identify the initial vegetation, while another PFT is activated later. my filter and documentation wording assume it is full set of PFTs used by run.

Would it make sense to keep this PR scoped to fixed PFT SA rather than redefine site.pft here ?

While checking this, I also found two separate bugs in the patch. A combined SA and ensemble call reuses the filtered design, and median only design fails while building the manifest. I’ll fix both and add tests before asking for another review

[infotroph]

Heads up that env will go away in #4229, at which point this test will probably need rethinking

[infotroph]

@divine7022

current segmented writer expects ENS run IDs and ensemble.samples files

Ah right, that would definitely complicate using it in SA 🫤. Yes, OK to keep this PR scoped to fixed PFTs.