fix(sos): order a set by its declaration, not by its coordinate labels

[FBumann]

(your intent here, handwritten)

Note

The following content was generated by AI.

Closes #892.

An SOS set now runs in the order its members are declared along sos_dim, rather than the order its coordinate labels sort into — the array order linopy reads everywhere else (isel, shift, roll, diff).

Why

Making the labels the SOS weights had two consequences:

• a string-labelled dimension could carry no set at all (ValueError: SOS constraint requires numeric coordinates), reaching piecewise the day its breakpoints are labelled [low, mid, high];
• numeric labels declared out of order silently redefined which members are adjacent. Two models identical member-for-member reached different optima depending only on what the coordinates were named, both reported optimal.

What does not change

Ascending numeric coordinates state the same order and are still passed through as the member weights, so a model whose SOS dimension is sorted is unaffected down to the bytes of its LP file — every piecewise formulation among them, since _validate_numeric_breakpoint_coords already requires strictly increasing breakpoints.

Descending coordinates are also meaning-preserving: reversing a set maps its consecutive pairs {i, i+1} to {n-i, n+1-i}, which are consecutive too, so SOS2's feasible set is unchanged. Only a sos_type=2 set whose numeric coordinates neither ascend nor descend genuinely regroups; it now warns, and sorting the index restores the previous behaviour. An sos_type=1 set cannot change meaning at all — its feasible region never depended on the order, reformulate_sos1 being x <= M * y and sum(y) <= 1 — so it stays silent.

Notes for review

• The numeric-coordinate requirement is dropped for both SOS types.
• reformulate_sos_constraints loses its argsort: that permutation is now always the identity, so it is deleted rather than rewritten. reformulate_sos2 selects the neighbouring segment indicators with isel instead of sel.
• test_sos2_unsorted_coords_matches_sorted passes both before and after, its best pair happening to coincide either way. That is why this was never caught, and why the new tests pick coefficients that separate the two orders.

Commits

1. test(sos) — five tests pinning the overlap where labels and declaration agree, plus seven strict xfails marking where they part. Self-verifying at that commit.
2. fix(sos) — the rule, with the xfail markers removed.

[codspeed-hq]

Merging this PR will regress 2 benchmarks

⚡ 6 improved benchmarks
❌ 2 regressed benchmarks
✅ 167 untouched benchmarks
⏩ 175 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Memory	test_to_lp[sos-n=1000]	2.4 MB	2.8 MB	-17.08%
❌	Memory	test_to_lp[knapsack-n=10000]	2.2 MB	2.7 MB	-15.96%
⚡	Memory	test_to_lp[masked-n=100]	2.7 MB	2.1 MB	+29.25%
⚡	Memory	test_to_lp[merge_balance-severity=0]	3.2 MB	2.6 MB	+21.84%
⚡	Memory	test_to_lp[rolling-severity=50]	429.7 MB	356.2 MB	+20.63%
⚡	Memory	test_to_lp[nodal_balance-severity=50]	3.2 MB	2.9 MB	+10.99%
⚡	Memory	test_to_lp[storage-n=10]	2.9 MB	2.6 MB	+10.33%
⚡	Memory	test_to_lp[storage-n=250]	36.1 MB	32.8 MB	+10.13%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing fluxopt:feat/sos-weights (b90e1ee) with master (65e36de)}

Footnotes

1. 175 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[FabianHofmann]

this looks good. I would include this in a bugfix release

[FabianHofmann]

I added a commit about for negative values and some smaller refactorings. this is good to go