search

lanl-ansi / Alpine.jl

A Julia/JuMP-based Global Optimization Solver for Non-convex Programs
https://lanl-ansi.github.io/Alpine.jl/latest/
Other
244 stars 39 forks source link

Resolving Ipopt not-enough-degree-of-freedom within POD #56

Closed jac0320 closed 7 years ago

jac0320 commented 7 years ago

This was a common case for castro_wastewater problems. Now it is showing up on gas problems from GasModels.jl. Anything associated with Ipopt can fail due to excessive equality constraints or fixed variable.

https://www.coin-or.org/Ipopt/documentation/node36.html

It is not POD's duty to control how the model should be implemented neither how sub-solvers should be tuned for conquering these problems. But there should be an easy switch as an attempt when such issue happens.

It can be a viable choice to treat the == constraints with >= & <=, which requires some complication on storing the original problem info in POD. This shouldn't hurt bounding performance much due to the presolve procedure in MIP solvers.

Any other suggestions?

rb004f commented 7 years ago

Yes, in the Gas Paper, when we went to ipopt, we replaced all variable x = constant with the constants and replaced many of the = constraints with 2 inequalities. If we are sending problems to ipopt where we fix the discrete variables, we should probably do the replace since those are problems POD is constructing. On the flip side, if we see the issue on the equality constraints, we should require put this on the user on whether or not to use == or <= and >= (?)

ccoffrin commented 7 years ago

In my experince the not-enough-degree-of-freedom message occurs when the model is over determined and has an error. I would say this is the user's responsibility to resolve.

jac0320 commented 7 years ago

Setup a notification to user to ask them considering replacing == with <= & >= in #58