model.remove_constraint() performance

Question

I'm working with CPLEX/docplex solving an LP problem that has a lot of infeasible constraints, most of the issues in feasibility come from the automated formulation of the model, and its hard to detect a priory the conflicts between constraints.

using the docplex functions ConflictRefiner().refine_conflict(model) im able to found, at least, one set of constraints in conflict.

The problem is that, in order to found all the sets of constraints in conflict, I have to remove some of the constraints in conflict using the function model.remove_constraint(constraint.name) and that function takes a long time to execute.

Edit the timings for 135.000 constraints are:

model.remove_constraint(constraint.name)
time= 124 sec
model.remove_constraint(constraint.element)
time= 126 sec

¿Is there a way to remove a constraint faster than with model.remove_constraint(str_name_constraint)?¿is there a way to get all the sets in conflict without having to remove/refine_conflict() for each set?¿is there a way to use hierarchy in constraints in order to avoid conflicts between constraints?

(last question its a little out of topic, but its related with the original problem)

thanks in advance!

Would you be better off not adding all the constraints at the start, then solving and finding defects in the solution and then adding the necessary constraints to fix those defects, and repeating that loop as often as necessary? This is a common approach used where there are very many possible constraints. — TimChippingtonDerrick, Dec 13 '16 at 14:26
This is a shot in the dark. The [documentation](https://cdn.rawgit.com/IBMDecisionOptimization/docplex-doc/master/docs/mp/docplex.mp.model.html#docplex.mp.model.Model.remove_constraint) says that you can either pass `remove_constraint` a "constraint object or a string". Did you try calling it like `model.remove_constraint(constraint)` rather than `model.remove_constraint(constraint.name)`? It's possible that would yield better performance ... then again, it might not help. — rkersh, Dec 13 '16 at 16:58
Hi @TimChippingtonDerrick, do you mean something like a cutting algorithm?, it could be a good approach, but if i have to use a modeling approach I will prefer something like a slack variables, because the nature of the constraints. I think that a cutting algorithm will be require a long executing time as same as the deleting constraints algorithm that Im using right now (Im thinking a solving/cutting iteration) — Pablo, Dec 13 '16 at 17:06
Hi @rkersh I try'd using the `constraint.element` before using the `constraint.name`, I use the reference from the object obtained from the `ConflictRefiner().refine_conflict(model)` list, but it takes almost the same, let me do the timings. — Pablo, Dec 13 '16 at 17:09
It looks like there is an undocumented `model.remove_constraints(constraints)` method as well. That is also worth a try. — rkersh, Dec 13 '16 at 17:27
@rkersh i add the timings for the first two options, i couldn't use `model.remove_constraints()` . because i don't know what type of argument needs (i tryed with lists and with only one element) — Pablo, Dec 13 '16 at 17:48
I was thinking more in terms of how we can solve problems like a tsp where adding all the constraints to stop cycles in the solution is not practical. Solving a simpler problem with some of the constraints missing could be quicker; and the solution might give you a basis to warm start the next solve when you have added some more constraints. — TimChippingtonDerrick, Dec 14 '16 at 18:36

Pablo · Accepted Answer · 2017-01-25T12:01:51.687

finally I used a workaround,

I didn't use mdl.remove_constraint(). to all the constraints i added a priority, and then I used the relaxer library provided by [docplex][1]. I couldn't found any example in the docs (or anywhere else) of the use of the relaxer, so i made one on my own (really simple to understand). The relaxer library is a really powerful tool, and its way much more easier to use rather than making all the relaxations by hand, especially when you have to deal with hierarchies in the constraints.

Example:

from docplex.mp.model import Model
import docplex

# we create a simple model
mdl = Model("relax_model")

x1=mdl.continuous_var(name='X1', lb=0)
x2=mdl.continuous_var(name='X2', lb=0)

# add conflict constraints
c1=mdl.add_constraint(x1<=10,'c1_low')
c2=mdl.add_constraint(x1<=5,'c2_medium')
c3=mdl.add_constraint(x1>=400,'c3_high')
c4=mdl.add_constraint(x2>=1,'c4_low')

mdl.minimize(x1+x2)

mdl.solve()
print mdl.report()
print mdl.get_solve_status() #infeasible model
print
print 'relaxation begin'

from docplex.mp.relaxer import Relaxer
rx = Relaxer(prioritizer='match')
rx.relax(mdl,relax_mode= docplex.mp.relaxer.RelaxationMode.OptInf)

print 'number_of_relaxations= ' + str(rx.number_of_relaxations)
print rx.relaxations()

print mdl.report()
print mdl.get_solve_status()
print mdl.solution

I know that this isn't "the solution" for the model.remove_constraint() performance problem, but it fits well when you need to avoid it.

model.remove_constraint() performance

1 Answers1