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

[Edward Lam]

Hi all,

I’m encountering this issue again. It appears that the function SCIPlpShrinkRows is removing my rows and they are not added back. Hence I’m generating identical cuts in different nodes. I have set removable to false but my cuts are still removed. Is there a way to stop my rows being removed or somehow force them back in after jumping nodes?

I have another issue. In the context of column generation, I think there is a bug in separating constraints instead of separating cuts. After adding a constraint, SCIP solves the LP relaxation which could be infeasible. If infeasible, SCIP immediately exits and doesn’t proceed to another round of pricing. If I remember correctly, it sets the lower bound to infinity and it exits by bound. I didn’t write down exactly which part of the code this happens. I’ve been separating cuts instead, which runs correctly.

Cheers
Eddie

> On 8 May 2019, at 3:36 pm, Gregor Hendel <hendel at zib.de> wrote:
> 
> 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 <mailto:Scip at zib.de>
>> https://listserv.zib.de/mailman/listinfo/scip <https://listserv.zib.de/mailman/listinfo/scip>
> 
> _______________________________________________
> 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/20210209/29c72e8c/attachment.html>