[SCIP] Duplicate rows in branch-and-cut-and-price

[Gregor Hendel]

Hi list,

Eddie and I discussed the subject in person some time ago, I just repeat 
the conclusion.

By separating a constraint such as setppc or knapsack instead of an LP 
row, you have more control of the behavior of this constraint through 
the use of its flags. After separating a constraint from within a 
separator, this constraint will be immediately added as a row to the LP 
relaxation, as well, as long as the "separate" flag is set to TRUE for 
the new constraints.
It is generally good if you can detect a constraint type that is more 
special than just linear, and create the corresponding constraint. A 
knapsack constraint, as an example, has much stronger propagation 
algorithms than its linear equivalent. In the pricing context, however, 
many possible deductions cannot be made on constraints that are modifiable.

Contrary to Eddie's assumption, there is no advantage in separating 
constraints instead of rows w.r.t. the primal heuristic behavior. 
Infact, the default primal heuristics of SCIP consider mostly the LP 
relaxation for their decisions, but do not consider specific constraint 
types at all.

Best,
Gregor

Am 19.02.19 um 22:55 schrieb Edward Lam:
> Hi all,
>
> I have a constraint handler that is adding setppc constraints (not 
> rows/cuts) in the enfolp callback. I expect the setppc constraint to 
> then add a row into the LP. It appears that sometimes this row is not 
> in the LP (or removed) so my separator is adding a duplicate setppc 
> constraint.
>
> This also occurs when I tried separating rows directly. Sometimes they 
> are not in the LP, so I’m separating the same rows again.
>
> Why does this occur? Is there a way to tell SCIP to simply add the 
> existing row back into the LP?
>
> Also, is there any benefit to separating constraints vs. rows? I 
> assume constraints will improve primal heuristics and propagation. 
> Although I’m not sure what can be propagated in column generation 
> since setting a variable to 0 will regenerate that column and setting 
> it to 1 will prevent future better columns from generating.
>
> Thanks in advance.
>
> Cheers
> Eddie
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20190508/7c869e74/attachment.html>