Add Gurobi Direct MINLP solver in contrib.solver#3745
Conversation
… from Gurobi's perspective. Starting to write the gurobi walker modeled after the sympy one
…on visitor, no real tests to speak of yet though
…I try to get the constraint objects...
…ngs like AbsExpression, we can't rely completely on the expression evaluation visitor, and I need to know the types of expressions. Starting to build out tests of the walker.
…inear expression tree, yay!!
…ressions in the RHS
…sionExpressions from the writer
jsiirola
left a comment
There was a problem hiding this comment.
A couple minor changes, and this should be good to go!
| raise NoSolutionError() | ||
|
|
||
| iterator = zip(self._pyo_vars, self._grb_vars.x.tolist()) | ||
| iterator = zip(self._pyo_vars, map(operator.attrgetter('x'), self._grb_vars)) |
There was a problem hiding this comment.
Is fetching the values one at a time slower than getting them in a single vector? (Same question applies to get_primals, get_duals. and get_redued_costs below)
There was a problem hiding this comment.
I don't know? If it is, this is much harder to generalize because the Gurobi MINLP version doesn't have the gurobi vars as a vector--they're already a list.
| gurobi_model, A, x, repn.rows, repn.columns, repn.objectives | ||
| gurobi_model, | ||
| A, | ||
| x.tolist(), |
There was a problem hiding this comment.
Because of the thing you commented on above, actually. I'm making this look the same as Gurobi MINLP so that they can use an identical SolutionLoader. Gurobi MINLP doesn't have the luxury of declaring the variables as a vector (I don't think? Although if I can dynamically add to one, that's another option, maybe?), so they're a list at this point right now.
| gurobi_model, | ||
| A, | ||
| x.tolist(), | ||
| list(map(operator.itemgetter(0), repn.rows)), |
There was a problem hiding this comment.
Why de-tupalize rows? aren't both values needed by the loader?
There was a problem hiding this comment.
I don't think so--the only time we need anything from this at all is to get the duals. And then you have to get the Pi attribute off each constraint. The difference is that was vectorized before too...
| @@ -0,0 +1,78 @@ | |||
| from pyomo.common.dependencies import attempt_import | |||
| @@ -0,0 +1,226 @@ | |||
| import math | |||
| # ___________________________________________________________________________ | ||
| # | ||
| # Pyomo: Python Optimization Modeling Objects | ||
| # Copyright (c) 2008-2024 |
| # ___________________________________________________________________________ | ||
| # | ||
| # Pyomo: Python Optimization Modeling Objects | ||
| # Copyright (c) 2008-2024 |
| # ___________________________________________________________________________ | ||
| # | ||
| # Pyomo: Python Optimization Modeling Objects | ||
| # Copyright (c) 2008-2024 |
|
I am not pushing the copyright changes yet - waiting for tests to finish since all the copyright stuff is NFC. |
|
But I DO have the changes ready to push as soon as the tests finish. |
| x1 = visitor.var_map[id(m.x1)] | ||
| x2 = visitor.var_map[id(m.x2)] | ||
|
|
||
| # Also linear, whoot! |
There was a problem hiding this comment.
Not changing but this is an abomination of a word. Woot? Yes. Hoot? Yes. Whoo? Yes. But WHOOT???
Fixes #3522 (except for the request to have a persistent MINLP interface to Gurobi)
Summary/Motivation:
This adds a new solver interface
gurobi_direct_minlpthat supports sending MINLP problems to Gurobi via the Python API. currently this is implemented as a separate Gurobi direct interface incontrib.solverso that we don't have negative performance implications forgurobi_direct_v2(and to punt for the moment on integrating the matrix-vector inferface with the general MINLP one).Changes proposed in this PR:
aux_var == general_nonlinear_exprequalities and linear/quadratic constraints involving the auxiliary and other variables.GurobiDirectincontrib.solver: The only thing special here is thesolvefunction which is again just unique because of the custom walker/writer explained above.Outstanding TODOs, none of which should prevent merging unless we want them to:
gurobi_nl_to_pyo_exprfunction, which will make them a lot more readable, and easier to maintain if every there is a change to the public API in gurobipy.Legal Acknowledgement
By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution: