[Scip] imposing branches of master in subproblem

[Gregor Hendel]

Hi Shahin,

I'm afraid there is another callback that you will need to implement to
get your code working, namely the 'consdelete' callback, which will then
be called at that particular place to appropriately free any constraint
data.

There is nothing wrong about the statement in the FAQ answer, but I see
a point in mentioning 'consdelete' because it becomes somewhat
fundamental whenever (ab)-using constraints as additional node data.

We will add a note to our FAQ about this.

Best,
Gregor


On 04/23/2014 10:09 PM, Shahin Gelareh wrote:
> Thank you Gerald for your explanations.
>
> well I got a step further:
> I end up with an assert error in cons.c:
>
>
>   /* free constraint data */
>    if( (*cons)->conshdlr->consdelete != NULL && (*cons)->consdata !=
> NULL && (*cons)->deleteconsdata )
>    {
>       SCIP_CALL( (*cons)->conshdlr->consdelete(set->scip,
> (*cons)->conshdlr, *cons, &(*cons)->consdata) );
>    }
>    else if( !(*cons)->deleteconsdata )
>       (*cons)->consdata = NULL;
>    assert((*cons)->consdata == NULL);
>
>
> I have a branchUp constraint and branchDown created at the root node.
> BranchUp constraint works fine (active/prop). When control goes in the
> ACTIVE of the branchDown constraints it seems like (immediately after
> calling active on the branchDown constraint) SCIP is now trying to get
> rid of the branchUP constraint and goes in SCIPconsFree to remove that
> branchUP constraint.
>
> first it checks whether the following holds:
>
>    if( (*cons)->conshdlr->consdelete != NULL && (*cons)->consdata !=
> NULL && (*cons)->deleteconsdata )
>
> otherwise if !(*cons)->deleteconsdata .
>
> For my constraint neither of these two holds, I do not know why. as a
> result assert((*cons)->consdata == NULL); throws an exception.
>
> Well I tried to follow:
> /"In general, all methods of the constraint handler (check, enforcing,
> separation, ...) should be empty (which means that they always return
> the status SCIP_FEASIBLE for the fundamental callbacks), just as if
> all constraints of this type are always feasible. The important
> callbacks are the CONSACTIVE and CONSDEACTIVE methods. /"
> in FAQ.
>
>
> I appreciate comments.
>
> Cheers
> Shahin
>
>
>
>
>
>
> On Mon, Apr 21, 2014 at 10:46 PM, Gerald Gamrath <gamrath at zib.de
> <mailto:gamrath at zib.de>> wrote:
>
>     Dear Shahin,
>
>
>         for my branch-and -price , I spent one day trying implement
>         (with minimal success) those stuffs in explained in  FAQ (also
>         looking at coloring example). The question in FAQ says:
>         "I want to store some information at the nodes and update my
>         pricer's data structures when entering a new node. How can I
>         do that?"
>
>         The explanation is talking about three different things
>         apparently.
>
>     No, it is not. You need to implement a constraint handler (similar
>     to examples/Coloring/src/cons_storeGraph.c), which
>     1) stores your branching decisions at nodes
>     2) updates your pricing problem when a node is entered or left
>     (CONSACTIVE/DEACTIVE)
>     3) checks master variables for their compatibility with the
>     branching decision of the current node (CONSPROP)
>
>     All this belongs together. In order to impose branching decisions
>     in the master problem, you need to update your pricing problem
>     w.r.t. these decisions and at the same time fix variables to zero
>     which don't comply with the decisions.
>
>         What I need is basically imposing branches in master problem
>         on variables of subproblem:
>         that is the last line of this FAQ question.
>
>         Well, I doubt that looking into the coloring example would be
>         a very straightforward way to understand how to do that, at
>         least for me :)
>
>         I have added
>
>            SCIP_CALL( SCIPaddConsNode(scip, upchild, up_branch_con,
>          NULL) );
>            SCIP_CALL( SCIPaddConsNode(scip, downchild,
>         down_branch_con, NULL) );
>
>           Now in the SCIP_DECL_PRICERREDCOST:
>         How does one recover this constraint and the data attached to
>         the current branch node? what about the whole history of
>         branches along the tree up to this node?
>
>     The idea of cons_storeGraph is to update the pricing problem
>     whenever a node in the tree is entered or left, such that when
>     your pricing problem is called, the internal data is always
>     correct. This is done in the CONSACTIVE and CONSDEACTIVE
>     callbacks. If you want to do this within the pricing, have a look
>     at COLORconsGetActiveStoreGraphCons(), which returns the
>     constraint corresponding to the current node or
>     COLORconsGetStack() which returns the complete stack of all
>     currently active constraints. Alternatively, you could also use
>     SCIPconshdlrGetConss() to get all constraints of your handler
>     which are active at the current node.
>     In order to get the data stored in a constraint, use
>     SCIPconsGetData() or (better) add external methods to your
>     constraint handler returning whatever you need.
>
>     Best,
>     Gerald
>
>
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20140424/2d56c59d/attachment.html>