[SCIP] Custom branching -- catching an assert

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


Hi Stefan,

No problem, I will simply remove the flag that is useless apparently!

Cheers,
Albert

On Tue, Jun 23, 2020 at 9:48 AM Stefan Vigerske <svigerske at gams.com> wrote:

> Hi,
>
> There can be problems if you define NDEBUG for your code that includes
> SCIP headers and link against a SCIP library that has been build with
> NDEBUG not defined (e.g., OPT=dbg). Some SCIP structs that your code
> will try to access to directly will then not match the structs that are
> used by code inside the SCIP library.
> This should be fixed in the next bugfix release.
>
> Best,
> Stefan
>
> PS: I cannot imagine that -DNDEBUG will disable anything in CPLEX
> (unless you build CPLEX from source, too).
>
> On 6/23/20 9:27 AM, Schrotenboer, Albert wrote:
> > 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
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > Scip mailing list
> > Scip at zib.de
> > https://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/50b145a3/attachment.html>


More information about the Scip mailing list