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 👎.}