[SCIP] Different results using SCIPchgVarUb and SCIPchgVarUbNode

[Gerald Gamrath]

Dear Diego,

there is no event for a node being created, so I guess you are catching 
the NODEFOCUSED event, which is called later, when the processing of the 
node starts? The point is that after creating the two child nodes, but 
before processing them, other nodes may be processed and variables added 
during pricing at those nodes. But since variables are global in SCIP, 
they will also be active at the previously created child nodes and may 
violate the branching decision taken, so your approach B is incorrect 
while approach A should be valid. Please have a look at the FAQ as well, 
in particular, 
https://scip.zib.de/doc-6.0.1/html/FAQ.php#pricerandnodedata for how 
branching decisions can be stored and enforced effectively.

Best,
Gerald

On 23.04.19 15:36, Diego Delle Donne wrote:
> Dear SCIP communit,
>
> I'm coding a Branch & Price with a branching rule quite similar to the 
> Ryan-Foster rule. So, when a branching is performed, some variables 
> need to be removed from the created nodes (i.e., fixed to 0).
>
> As a first approach (approach A), I had an ObjEventhdlr which is 
> called when a node is created. It checks every existing variable and 
> if it needs to be removed the variable is fixed to 0. I do this by 
> calling SCIPchgVarUb(...) within the scip_exec(...) method of my 
> ObjEventhdlr.
>
> This works fine, but I noted that it shouldn't be necessary to iterate 
> through EVERY existing variable each time I branch, since the number 
> of variables to be fixed is usually just a small portion of the 
> existing ones. Moreover, in my code, when I perform a branching, I 
> already have access to the (small) list of variables which should be 
> fixed. Hence, I tried to fix them at the moment of the node creation 
> (within the scip_execlp(...) method of my ObjBranchrule object) by 
> using SCIPchgVarUbNode(...), and forgetting about my ObjEventhdlr.
>
> This new approach (approach B) seems to work fine also and it is 
> usually faster than the first one (of course, that was the goal!), but 
> I have found some funny differences in some cases. For instance, 
> sometimes the rounding heuristic in approach A finds better solutions 
> than the one in approach B. This allows approach A to end the solving 
> process faster than approach B, although being "slower" for the first 
> part of the process.
>
> Any ideas on what's causing this behavior? I would think that the 
> solving process should be the same for both approaches, as I am just 
> omitting to iterate through a bunch of variables which I won't change 
> anyway. Does SCIPchgVarUb(...) behave differently from 
> SCIPchgVarUbNode(...) in some way?
>
> Thanks in advance!
> Best regards to all
> Diego
>
>
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 
> 	Libre de virus. www.avg.com 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> 
>
>
>
> _______________________________________________
> 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/20190424/9b194c9e/attachment.html>