Choosing an optimisation problem "backend"ΒΆ
On loading a model, there is no solver backend, only the input dataset.
The backend is generated when a user calls build() on their model.
By default this will call back to Pyomo to build the model and send it off to the solver given by the user in the run configuration config.solve.solver.
Pyomo has the benefit of mutable input parameters, which allows you to update parameter values in your optimisation problem without having to re-build any Pyomo objects. However, it is otherwise a relatively memory and time-consuming library for building optimisation problems.
Since larger models tend to require a commercial solver to successfully complete in a reasonable amount of time (see our solver comparison for justification), we have also introduced a direct interface to the Gurobi solver Python API. Our tests show that this reduces peak memory consumption and time to solution compared to using the Pyomo backend with Gurobi as the solver in both cases. If you have access to a Gurobi license, this does not require any extra effort on your part, besides having to:
-
Ensure the Gurobi Python library is installed in your Calliope environment:
-
Select the Gurobi backend:
You can still interface with your optimisation problem, but some methods will raise an exception when the Gurobi Python API does not allow for something that the Pyomo API does.
If you do not have access to a commercial solver, there is also a direct interface to the open-source HiGHS solver via its Python API (highspy), which is installed with Calliope by default.
As with the Gurobi backend, building your optimisation problem this way is faster and less memory-intensive than going via Pyomo.
To use it, select the HiGHS backend in your YAML configuration (config.build.backend: highs) or at build time (model.build(backend="highs")).
Note that the HiGHS backend does not yet support piecewise constraints and cannot un-fix fixed variables without a rebuild.