[SCIP] Using debugsol with branching rules

[Matheus Ota]

Dear Ambros,

Thank you for the reply! Indeed my "check" flag was set to TRUE. However,
after changing it to FALSE, I'm still getting reported that the debug
solution violates a branching constraint, like for example

> ***** debug: row <branching1> violates debugging solution (lhs=2, rhs=2,
> activity=[4,4], local=1, lpfeastol=1e-06)
> branching1: 2 <= +1<t_x_14,15> +1<t_x_13,15> +1<t_x_12,13> +1<t_x_12,14>
> +1<t_x_11,12> +1<t_x_11,15> +1<t_x_10,12> +1<t_x_10,15> +1<t_x_9,12>
> +1<t_x_9,15> +1<t_x_8,12> +1<t_x_8,15> +1<t_x_7,8> +1<t_x_7,9> +1<t_x_7,10>
> +1<t_x_7,11> +1<t_x_7,13> +1<t_x_7,14> +1<t_x_6,7> +1<t_x_6,12>
> +1<t_x_6,15> +1<t_x_5,6> +1<t_x_5,8> +1<t_x_5,9> +1<t_x_5,10> +1<t_x_5,11>
> +1<t_x_5,13> +1<t_x_5,14> +1<t_x_4,6> +1<t_x_4,8> +1<t_x_4,9> +1<t_x_4,10>
> +1<t_x_4,11> +1<t_x_4,13> +1<t_x_4,14> +1<t_x_3,4> +1<t_x_3,5> +1<t_x_3,7>
> +1<t_x_3,12> +1<t_x_3,15> +1<t_x_2,4> +1<t_x_2,5> +1<t_x_2,7> +1<t_x_2,12>
> +1<t_x_2,15> +1<t_x_1,4> +1<t_x_1,5> +1<t_x_1,7> +1<t_x_1,12> +1<t_x_1,15>
> +1<t_x_0,4> +1<t_x_0,5> +1<t_x_0,7> +1<t_x_0,12> +1<t_x_0,15> <= 2


Also in this topic, I think that I'm still confused by what the flag means.
Is there a more precise description somewhere? The "check" flag for
example, I set it to TRUE because I thought that branching inequalities
were not redundant. Here is how I'm creating the branching inequalities:

SCIP_CALL(SCIPcreateConsLinear(scip, &cons1, "branching1", 0, NULL,
> NULL,2.0, 2.0, TRUE, FALSE, FALSE, FALSE, TRUE,TRUE, TRUE, FALSE, FALSE,
> TRUE));
> SCIP_CALL(SCIPcreateConsLinear(scip, &cons2, "branching2", 0, NULL, NULL,
> 4.0, SCIPinfinity(scip),TRUE, FALSE, FALSE, FALSE, TRUE, TRUE, TRUE, FALSE,
> FALSE, TRUE));


I then create the child nodes:

> SCIP_CALL(SCIPcreateChild(scip, &child1, 0.0,
> SCIPgetLocalTransEstimate(scip)));
> SCIP_CALL(SCIPcreateChild(scip, &child2, 0.0,
> SCIPgetLocalTransEstimate(scip)));


And add the constraints to the nodes:

> SCIP_CALL(SCIPaddConsNode(scip, child1, cons1, NULL));
> SCIP_CALL(SCIPaddConsNode(scip, child2, cons2, NULL));


Thanks again for your time,
Matheus

Em sáb., 2 de jul. de 2022 às 09:06, Ambros Gleixner <gleixner at zib.de>
escreveu:

> Dear Matheus,
>
> Your approach with the debug solution is definitely right.  The fact
> that branching inequalities are reported as violated constraints,
> however, could mean that you are not using the right flags for your
> branching constraints.  Can it be that the "check" flag is set to TRUE?
>   This should not be the case, since they do not belong to the
> definition of feasibilty.
>
> Best,
> Ambros
>
>
> Am 01.07.22 um 02:29 schrieb Matheus Ota:
> > Dear Scip Community,
> >
> > I'm currently trying to debug my C++ program which incorrectly outputs a
> > non-optimal solution. I have a minimization problem and I have a
> > solution with value 673. My program when executed on my computer claims
> > that a solution with value 674 is optimal. However, if I execute this
> > program on another computer, it correctly outputs a solution with value
> > 673. There are also instances where my computer is correct, but the
> > other computer is not.
> >
> > In order to debug this problem I've compiled SCIP with -DDEBUGSOL=on and
> > I'm using the parameter "misc/debugsol" to pass the solution with value
> > 673. One thing to mention is that I have custom branching rules which
> > were implemented via constraint handlers. When I execute the program
> > with the debug solution it is printing a lot of violated constraints in
> > the terminal, however, the violated constraints all seem to correspond
> > to the branching inequalities. Is there a way to suppress the errors
> > specifically for these inequalities?
> >
> > Also, I would be thankful for any help here (as I'm getting out of ideas
> > of where the bug is)! I've checked my branching constraints and indeed,
> > if a solution is cut-off in one branch, then it is present in the other
> > branch. So the branching constraints are just partitioning the set of
> > feasible solutions (as expected).
> >
> > Thanks for your time,
> > Matheus
> >
> > _______________________________________________
> > Scip mailing list
> > Scip at zib.de
> > 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/20220702/6af7ddb8/attachment.html>