Solver Refactor and Extension

[FabianHofmann]

Currently information about solver state and meta info is split across multiple places:

• Model: solver_model, solver_name, status, termination_condition
• Result: status, solution, solver_model
• Solver: only solver_options
• Model.solve(): inlined result-to-model mapping logic (normal, remote, and mock paths each have independent mapping)
• solver_capabilities.py: global capability lookup
• direct conversion entry points live on Model (delegating to linopy/io.py functions)

We want to refactor to better encapsulate needed information.

Changes to Solver Class

The following new attributes:

• options: dict[str, Any]
• status: Status | None
• solution: Solution | None
• report: SolverReport | None -> new object containing solver times and other meta data from solving (potentially come up with a different name
• solver_model: Any
• io_api: str | None
• capability: SolverInfo | None
• env: gurobipy.Env | None (and other solver envs)
• solver_name: str (current)

and the following functions:

• to_solver_model(model, explicit_coordinate_names=False, env=None): thin wrapper around existing linopy/io.py conversion functions (model.to_gurobipy(), model.to_highspy(), raises NotImplementedError for solver wo interface
• update_solver_model(model, explicit_coordinate_names=False, env=None): synchronize native solver model after linopy model changes. Not implemented now
• resolve(sense) -> Result: solve or re-solve self.solver_model. Stores result on the solver instance (self.status, self.solution, self.solver_model) and returns Result. Raises if self.solver_model is None.

(Note currently the Gurobi Env is created inside a contextlib.ExitStack scoped to solve_problem_from_model() — if solver_model persists beyond solve(), the env must also persist)

Assign the Solver instance to the linopy model at model.solver (add "solver" to __slots__), None at initialization

Changes to Result Class

Add solver_name: str to the Result dataclass. Currently Result holds status, solution, and solver_model. Adding solver_name makes Result fully self-describing — no need to pass solver identity out-of-band.

Changes to Model class

• Add apply_result(result: Result | None = None) -> tuple[str, str] as proposed in Solver Refactor and Extension #628 but witht the difference when result is None, pull the result from self.solver (reads self.solver.status, self.solver.solution, self.solver.solver_model). This enables a clean post-resolve() flow where the solver already has the result. When result is provided explicitly, use it directly (for remote solve, mock, or detached workflows). Used for status and termination updates, objective assignment, primal and dual value assignments.

• Model.solver_model should point to Model.solver.solver_model.

• Model.solver_name should point to Model.solver.solver_name.

[FBumann]

From discussion:

• solver_capabilities.py: rather as class attribute with capabilities per solver class
• lp as default option for all solvers. solve_problem_from_file kept for now.
• Solver stores solution as pd.Series. linopy.Model.solution does conversion to xarray+dims/coords

[FabianHofmann]

update model and solver_model with diffing logic

• diff can be obtained from two instances of the "same shape"
• diff can be created and collected from constraints update
• diff is stored until resolve is applied

[alexfias]

I think this refactor would also help a GUI/integration use case I ran into with PyPSA + linopy.

I am building a use case around PyPSA optimisation and wanted to support cancelling a running solve. Right now, after creating the model, network.model exists and is a linopy.Model, but during the solve network.model.solver_model is still None. So it looks like there is no accessible live solver handle to call something like terminate() on?

So, the current limitation is not just where status/meta information is stored, but also that there is no persistent exposed solver object during solving. If model.solver / model.solver_model persisted as part of this refactor, that could enable:

• cancellation/interruption for instance from a GUI
• progress/log reporting
• access to solver metadata while the solve is running

So this seems highly relevant for interactive workflows, not only for internal API cleanup.