Too many constraints when using ipopt

[rb004f]

If you create a model with many constraints on the binary variables, you can create an artificial situation where a convex solver like ipopt will complain there are too few degrees of freedom. However, given a fixed solution on the binary variables, these constraints are just constant tautologies.

This situation can come up in cutting plane methods where many constraints are added on the integer variables that are never active in the convex solver. And if you have too many, the convex solver will throw an artificial error. Without knowing the details of the internal architecture, I suggest simply dropping all constraints that only consist of binary variables when creating the continuous problem.

example (silly) code

using JuMP
using Ipopt
using Cbc
using Juniper


optimizer = Juniper.Optimizer
params = Dict{Symbol,Any}()
params[:nl_solver] = with_optimizer(Ipopt.Optimizer)

using LinearAlgebra # for the dot product
m = Model(with_optimizer(optimizer, params))

v = [10,20,12,23,42]
w = [12,45,12,22,21]
x = @variable(m, x[1:5], Bin)

@objective(m, Max, dot(v,x))

@NLconstraint(m, sum(w[i]*x[i]^2 for i=1:5) <= 45)   

for i=1:500
  @constraint(m, x[1] + x[2] == 1)
end

JuMP.optimize!(m)

[ccoffrin]

Based on my experience using solvers like Ipopt, I think it's best to handle these issues at the modeling later and not the solver layer. Every time I have ran into the "too few degrees of freedom." message there has been a fairly significant issue in my model.

Your proposed fix,

dropping all constraints that only consist of binary variables

Will work for some cases, like the one you suggest, but the same issue can come up only when using continuous variables. One fairly generic solution would be to develop an NLP pre-solver that can help clean up a JuMP model before sending it to a solver, but I think that feature would be better in JuMP, than in Juniper.

[odow]

+1 on the NLP presolver. There's a lot of scope for cleaning up user-provided models into ones that the solvers more readily accept.

[rb004f]

Yes, that gets a little closer to a constraint management system. The use case I have here is looking at using juniper inside of a cutting plane algorithm where cuts are generated dynamically and those cuts look like 1 = 1 or 0 <= 1 to ipopt.

[ccoffrin]

In that specific case I would double check that 1 = 1 is being interpreted as a fixed variable and do some cut management on the algorithm side to remove redundant cuts.

[rb004f]

This would happen internally in juniper after binary variables are resolved... Example

Cutting plane method generates a constraint like

x[1] + x[2] <= 1

At a leaf, juniper generates a candidate solution of x[1] =0 and x[2] = 0 which gets passed to ipopt. This constraint goes to ipopt as essentially a constraint of the from 0 <= 1.

[ccoffrin]

closing in favor of the original pre-solver issue #87.