refactor(sos): add Model.apply/undo_sos_reformulation methods

[FBumann]

Summary

On top of the following this PR includes changes from #691

Stateful pair of methods on Model that own the SOS reformulation lifecycle. Model.solve(reformulate_sos=...) delegates to them; same external behavior.

• Model.apply_sos_reformulation() — stashes the token on _sos_reformulation_state. Raises RuntimeError if already applied.
• Model.undo_sos_reformulation() — restores the original SOS form. No-op if nothing is applied.
• Solver._build() — raises ValueError when an SOS-bearing model meets a solver without SolverFeature.SOS_CONSTRAINTS, so the low-level Solver.from_model(...).solve() path is safe without going through Model.solve().

Persistence:

• Model.copy() / copy.copy / copy.deepcopy deep-copy the token; the copy is independently undoable.
• to_netcdf() raises if reformulation is active — undo first.

Why the lifecycle lives on Model, not on Solver

I considered three alternatives and rejected all of them:

On Solver.from_model() with undo on solver.close(). Tempting because Solver already manages env lifecycle. Rejected: reformulation is a model transformation, and the Solver only queries a feature flag — putting the lifecycle there makes Solver responsible for work it doesn't perform.

Build-time reformulation inside _build_*, no model mutation. Cleanest in theory. Rejected because the mutation is a feature: users can print the reformulated MILP, export it to LP/MPS, or write additional constraints referencing the aux binaries. Hiding it inside the build step strips all of that.

Standalone context manager. Rejected: it only handles the transient (auto-undo) case. The method pair supports transient, permanent, and decide-later workflows; a 3-line context manager over the methods can be added later if wanted.

What's left on Solver: one feature-flag check in _build(). Layering:

Layer	Role
sos_reformulation.py	implementation primitives
Model	owns transformation state — apply / undo / inspect
Solver	declares feature support; raises on incompatible state
Model.solve()	bracketing for the one-shot ergonomic

Context

Same thread as #688. While reviewing the two-step Solver.from_model().solve() API from #682, I noticed Model.solve() was doing orchestration the Solver path couldn't reproduce. This PR addresses the SOS slice; validation / sanitization lifting can follow separately.

Test plan

• pytest test/test_sos_reformulation.py — 69 tests, 9 new (apply/undo primitives, copy across all three protocols, netcdf guard, Solver-path raise).
• pytest test/test_sos_constraints.py test/test_optimization.py test/test_io.py — 1544 pass.
• ruff check, ruff format, mypy linopy/{model,solvers,io}.py clean.

🤖 Generated with Claude Code

[FBumann]

@FabianHofmann This is probably the heavy lifting of #688

[FBumann]

@FabianHofmann Look at the reasoning in #691, where the guideline "Mutating the Model is done deliberately before using a Solver" also affects sanitization etc

[FabianHofmann]

yes, makes sense too. should we merge into #691 since they both go in the same direction? would make it easier for reviewing I'd say

[FBumann]

@FabianHofmann #691 is stacked on top anyway. So we can just clos this and point the other to master. But i thought this deserves its own deliberate PR with description and reasoning etc.
But feel free to do the review in #691.
Id like to merge them sequentially into master though.

[FabianHofmann]

@FabianHofmann #691 is stacked on top anyway. So we can just clos this and point the other to master. But i thought this deserves its own deliberate PR with description and reasoning etc. But feel free to do the review in #691. Id like to merge them sequentially into master though.

was confused with the references. that makes sense. I am reviewing #691 quickly and if you don't mind we merge #691 to here and I have another look at the combined diff. would that be fine?

[FBumann]

I would rather merge them both into master sequentially, so we keep the PR's in master. But Its not really important to be honest. Do as you please

[FabianHofmann]

Code review

Found 1 issue:

1. Model.solve(reformulate_sos=True|"auto") leaks _sos_reformulation_state if Solver.from_name() or solver.solve() raises. The undo lives in a finally around assign_result() (lines 1830–1832), but from_name and solve are wrapped by a separate try/finally whose only job is file cleanup (lines 1788–1825). On any build/solve failure the second try is never reached, the model stays in reformulated form, and the next Model.solve() call hits RuntimeError: SOS reformulation has already been applied from apply_sos_reformulation (lines 1243–1245). Suggest a single try/finally wrapping both blocks so the auto-undo contract documented on apply_sos_reformulation actually holds for the transient case.

linopy/linopy/model.py

Lines 1786 to 1833 in 68d75cd

	self.constraints.sanitize_infinities()
	try:
	self.solver = None # closes any previous solver
	if io_api == "direct":
	if set_names is None:
	set_names = self.set_names_in_solver_io
	build_kwargs: dict[str, Any] = {
	"explicit_coordinate_names": explicit_coordinate_names,
	"set_names": set_names,
	"log_fn": to_path(log_fn),
	}
	if env is not None:
	build_kwargs["env"] = env
	else:
	build_kwargs = {
	"explicit_coordinate_names": explicit_coordinate_names,
	"slice_size": slice_size,
	"progress": progress,
	"problem_fn": to_path(problem_fn),
	}
	self.solver = solver = solvers.Solver.from_name(
	solver_name,
	model=self,
	io_api=io_api,
	options=solver_options,
	**build_kwargs,
	)
	if io_api != "direct":
	problem_fn = solver._problem_fn
	result = solver.solve(
	solution_fn=to_path(solution_fn),
	log_fn=to_path(log_fn),
	warmstart_fn=to_path(warmstart_fn),
	basis_fn=to_path(basis_fn),
	env=env,
	)
	finally:
	for fn in (problem_fn, solution_fn):
	if fn is not None and (os.path.exists(fn) and not keep_files):
	os.remove(fn)
	try:
	return self.assign_result(result)
	finally:
	if applied_sos_reformulation_here:
	self.undo_sos_reformulation()

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[FBumann]

I thought someone might need it to use sos reformulation with remote/oetc. Doesnt this go through netcdf?

[FabianHofmann]

that is totally true. so would be nice to support it

[FabianHofmann]

@FBumann should I quickly do that?

[FBumann]

Ill do it

[FabianHofmann]

after thinking about it, I would actually like to have that as a follow up where we touch more on logic how to store sos attributes. so this should not be a blocker for now

[FBumann]

For me it doesnt feel hacky. We treat oetc/remote like we do any solver: Mutate the Model, the solver gets only what he needs. This perfectky trasitions to #683, with OETC behaving like a regular solver.
IO Is now not needed, but can be added anyway (dropping data on IO is never the best option)

[FBumann]

@FabianHofmann If you disagree, we can discuss it. Im not using oetc...

[FabianHofmann]

fine, let's me add a commit to streamline the code in solve now. many lines are they only for the purpose of reformulation awareness. I'll draft something and likely move the reformulation hanlding into the functions solve_on_* with a context manager

[FBumann]

I would maybe defer that after we close #683 ? Then we cleanly refactor? But we can also do it twice, i dont mind

[FabianHofmann]

#683 is way more invasive than the small refactor above, have it ready. just reviewed locally and pushing it here. improves the readability of solve significantly

[FabianHofmann]

@FBumann ready to go. if you want take a look at my latest commit. if you agree, feel free to merge

[FBumann]

@FabianHofmann Looks good.