[SCIP] Custom branching -- catching an assert

Schrotenboer, Albert a.h.schrotenboer at rug.nl
Tue Jun 23 09:27:47 CEST 2020


Dear Gerald (and others)

Thank you for the clarification (months ago). I've been implementing it in
the way you suggested, everything seems ok, but then I encountered some
weird behaviour.

I compile the code  in normal mode -> seems to work fine
I compile the code in DBG=opt mode -> seems to work fine

In my program I also have some upper bounds that use plain CPLEX, so I
decided to use the flag -DNDEBUG while compiling, which is (as far as I
know) disabling CPLEX debug mode

When I now compile my code in DBG=opt mode with the -DNDEBUG flag, I catch
an assert somewhere within scip:
JRP: src/scip/tree.c:1214: SCIPnodePropagateAgain: Assertion `node != NULL'
failed.

Do you maybe know if this flag is the cause of any unspecified behavior? Of
course, it is a bit weird to use debug mode and to tell at the same time to
not debug (via the flag), but I want to make sure things are correct.


Kind regards,
Albert


On Thu, Jan 9, 2020 at 12:46 PM Gerald Gamrath <gamrath at zib.de> wrote:

> Dear Albert,
>
> changing the upper bound to 0 to enforce your decision is correct.
> However, your consactive method should only mark the constraint to be
> repropagated; afterwards, propagation will be called where you should
> adjust the bounds. Since the bound is only changed at the current node,
> SCIP will automatically undo this when the current subtree is left and
> re-install the bound when it is re-entered. In the latter case, you thus
> only need to propagate variables added in the meantime.
>
> For more details, see
> https://scip.zib.de/doc-6.0.2/html/FAQ.php#pricerandnodedata or have a
> look at the binpacking example.
>
> Best,
> Gerald
>
> Am 09.01.20 um 10:45 schrieb Schrotenboer, Albert:
>
> Dear SCIP Community,
>
> I am solving a basic VRP with branch & price, and have a question
> regarding a branching rule I've implemented (Actually, I forgot how to do
> it...) I branch on x_{ij} arcs, which I identify with my branchrule object.
> To handle this information down the b&b tree, I use a constraint handler
> with the following virtual methods implemented:
>
> SCIP_DECL_CONSTRANS(ObjConshdlrOwn::scip_trans)
>       To transform the info, nothing special
> SCIP_DECL_CONSACTIVE(ObjConshdlrOwn::scip_active)
>       Here I search which of my generated routes should be fixed to zero
> corresponding to my branching information. (I also do the appropriate
> adaptations in my pricing based on the branching). I fix my variables by
> the following routines:
>
> if (SCIPvarGetUbLocal(var) > 0.01)
>       SCIP_CALL(SCIPchgVarUb(scip, (*d_varConsInfo).v_path[r].d_var, 0.0)
> );
>
> This all works nicely (when I do not run in debug mode). When I run in
> Debug mode, however, an assert is collapsing when SCIP alters the path of
> the tree (when it backtracks a few nodes), saying that:
> JRP: src/scip/tree.c:1803: SCIPnodeAddBoundinfer: Assertion
> `(SCIP_NODETYPE)node->nodetype == SCIP_NODETYPE_FOCUSNODE ||
> (SCIP_NODETYPE)node->nodetype == SCIP_NODETYPE_PROBINGNODE ||
> (SCIP_NODETYPE)node->nodetype == SCIP_NODETYPE_CHILD ||
> (SCIP_NODETYPE)node->nodetype == SCIP_NODETYPE_REFOCUSNODE || node->depth
> == 0' failed.
>
> My question is, therefore, the following: Is changing the UB to enforce
> variables to 0 the correct way to go? In addition, am I required to
> implement the deactive virtual method as well, to change the upper bounds
> back to what they were?
>
> Kind regards,
> Albert
>
> --
>
> Albert Schrotenboer
>
> Postdoctoral Researcher
>
> Faculty of Economics and Business
>
> University of Groningen
>
> P.O. Box 800, 9700 AV Groningen
>
> _______________________________________________
> Scip mailing listScip at zib.dehttps://listserv.zib.de/mailman/listinfo/scip
>
>
>

-- 

dr. Albert Schrotenboer

Postdoctoral Researcher

Faculty of Economics and Business

University of Groningen

P.O. Box 800, 9700 AV Groningen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20200623/6d6474fe/attachment.html>


More information about the Scip mailing list