[divine7022]

Description

run.write.configs drops design rows that move a trait of a PFT not listed in the site's <site.pft>, before the SA runs are written. If none of the site's PFTs were sampled nothing is dropped, the same rule write.ensemble.configs uses.

Motivation and Context

write.ensemble.configs() gives each site only its own PFTs' parameters, so a run moving another PFT's trait was an exact copy of the median run. The old write.sa.configs() skipped them.
In my 100 site statewide design this was 633 runs per site instead of 157

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.