<div dir="ltr"><div>Thank you Gerald for your explanations.<br><br></div><div>well I got a step further:<br></div><div>I end up with an assert error in cons.c:<br><br><br> /* free constraint data */<br> if( (*cons)->conshdlr->consdelete != NULL && (*cons)->consdata != NULL && (*cons)->deleteconsdata )<br>
{<br> SCIP_CALL( (*cons)->conshdlr->consdelete(set->scip, (*cons)->conshdlr, *cons, &(*cons)->consdata) );<br> }<br> else if( !(*cons)->deleteconsdata )<br> (*cons)->consdata = NULL;<br>
assert((*cons)->consdata == NULL);<br><br><br></div><div>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. <br>
<br></div><div>first it checks whether the following holds:<br><br></div><div> if( (*cons)->conshdlr->consdelete != NULL &&
(*cons)->consdata != NULL && (*cons)->deleteconsdata )</div><div><br></div><div>otherwise if !(*cons)->deleteconsdata .<br><br></div><div>For my constraint neither of these two holds, I do not know why. as a result assert((*cons)->consdata == NULL); throws an exception.<br>
</div><div><br></div><div>Well I tried to follow:<br><i>"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.
</i>"<br></div><div>in FAQ.<br></div><div><br><br></div><div>I appreciate comments.<br><br></div><div>Cheers<br>Shahin<br></div><div><br></div><div><br><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Apr 21, 2014 at 10:46 PM, Gerald Gamrath <span dir="ltr"><<a href="mailto:gamrath@zib.de" target="_blank">gamrath@zib.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Shahin,<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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:<br>
"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?"<br>
<br>
The explanation is talking about three different things apparently.<br>
</blockquote></div>
No, it is not. You need to implement a constraint handler (similar to examples/Coloring/src/cons_<u></u>storeGraph.c), which<br>
1) stores your branching decisions at nodes<br>
2) updates your pricing problem when a node is entered or left (CONSACTIVE/DEACTIVE)<br>
3) checks master variables for their compatibility with the branching decision of the current node (CONSPROP)<br>
<br>
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.<div class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What I need is basically imposing branches in master problem on variables of subproblem:<br>
that is the last line of this FAQ question.<br>
<br>
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 :)<br>
<br>
I have added<br>
<br>
SCIP_CALL( SCIPaddConsNode(scip, upchild, up_branch_con, NULL) );<br>
SCIP_CALL( SCIPaddConsNode(scip, downchild, down_branch_con, NULL) );<br>
<br>
Now in the SCIP_DECL_PRICERREDCOST:<br>
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?<br>
</blockquote></div>
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 COLORconsGetActiveStoreGraphCo<u></u>ns(), 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.<br>
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.<br>
<br>
Best,<br>
Gerald<br>
</blockquote></div><br></div>