Repository navigation
sipnet: Drop same-pft segments #4122
Description
write_segmented_configs chooses where to place segment boundaries by parsing either a cycles.csv or an events json file to find the planting events where crop_code changes from its previous state, ie it finds the times when the event file thinks the crop type changed.
At config time, write_segmented-configs uses a user-supplied crop-to-pft mapping function to determine which PFT to use when configuring each segment. But! If several segments in a row have different crop codes that map to the same PFT, we still generate a restart even though results will be identical to what we would have gotten by running all of these as one segment.
Segments are expensive in runtime, scratch space, file count, and conceptual overhead, so we should not be generating extra segments that have no effect.
Proposed fix: In write_segmented_configs, perform PFT mapping as now but then pause and check for segment transitions that keep the same PFT. Drop these and edit the start time of each retained segment to keep the runs continuous.
Deeper design question: It's reasonable to think we'll eventually want to support segmented runs that restart for reasons other than PFT changes. Can we do anything in this patch to make that easier to implement when we need it?
Activity
S1DDHEY commentedon Sep 24, 2026
Adding to the proposed fix, we could isolate the merge logic behind something like a
can_merge_segments()check so future non-PFT restart reasons can be handled, without changing much.tyagivibhor111-hub commentedon Sep 25, 2026
I think the fix should be to keep the existing crop-code based segmentation, map each segment to its PFT as it does now, and then check consecutive segments for the same PFT.
If two adjacent segments map to the same PFT, we can merge them and adjust the start/end time so the run stays continuous. If the PFT is different, the segment boundary should remain.
For example:
crop A → PFT 1crop B → PFT 1crop C → PFT 2would become:
PFT 1 → PFT 2instead of creating a separate restart for crop A → crop B.
I think keeping this merge step separate, possibly through a
can_merge_segments()check, would also fit the proposed fix.@infotroph, does this match the expected approach for this issue, or is there a specific behavior you want the implementation to follow?