[Scip] SCIPgetTransformedCons

[Gerald Gamrath]

Hi Jose,

as you said, the event_boundwriting example copies the subproblem of the 
current node. After that, the sub-SCIP is solved until the end of the 
root node, which means that presolving is performed and cutting planes 
are generated. This would not be done if we would just solve the current 
node in the tree. So the value of the LP relaxation in the sub-SCIP 
should be better (or equal) than the LP relaxation value at the current 
node.

If you want to see the value of the LP relaxation at each node, you can 
activate the corresponding display column (display/lpobj/active = 2) and 
set the display frequency (display/freq) to 1.

If you do branch-and-price, no node should be pruned by bound without 
calling the pricer first (unless a new primal bound was found that cuts 
off parts of the tree). If the LP value is too bad and would lead to a 
cutoff, the pricer is called, anyway, because by adding new variables it 
might decrease the LP value.
What can happen is that your branching leaves you with an LP that is 
infeasible. In this case, you do not have dual values, so "normal" 
reduced cost pricing cannot be applied. Therefore, a pricer should 
implement the additional Farkas pricing callback. This one is called for 
an infeasible LP and works on the values of the dual ray proving 
infeasibility instead of the dual solution values. You can access these 
values by, e.g., SCIPgetDualfarkasLinear().

Best,
Gerald and Michael

Am 18.05.2012 09:02, schrieb Jose Walteros:
> Hi all,
>
> I was able to adapt the event_boundwriting example that you have in 
> order to catch information when each node is processed. There are a 
> couple of questions that I have about it:
>
> 1. As I see it base on the code in the file event_boundwriting.c when 
> DEFAULT_WRITESUBMIPDUALBOUND option is as true, you construct a new 
> model, copy the bounds, and then, solve it to find the value of the LP 
> relaxation at that node. Is this correct?
>
> 2. As I mentioned before, something that I am noting is that SCIP is 
> pruning nodes in the B&B tree that are not supposed to be pruned. SCIP 
> is not even calling the pricer in those node (and because of this 
> reason I don't even know if the LP relaxation is solved in this 
> nodes). I would like to know if it is possible to use this handler do 
> find why the node was pruned (if it was by bound or by infeasibility)?
>
> -Jose
>
> On May 17, 2012, at 6:52 PM, Jose Walteros wrote:
>
>> Hi all,
>>
>> I coded a Branch and price using the binpacking example as a a 
>> starting point. So far everything is working and the code is running, 
>> I was able to solve the previous problems that I had before.
>>
>> I am currently running some tests and I found that the pricer problem 
>> is not being called while solving some nodes in the b&b tree (my 
>> impression is that maybe the nodes are cut by infeasibility, but I 
>> want to be sure about the reason). What I have seen, at least for the 
>> instances that I am using, is that SCIP by default solves the tree 
>> using a depth first search (it might not be the case always, but for 
>> the instance that I am running, it explores the tree in this 
>> fashion). I am using as a branching rule a very similar rule compared 
>> to the Ryan Foster's, that comes with the binpacking example. I was 
>> wondering if there is a simple way to access the value of the 
>> objective function at each node and also to find out if the node was 
>> cut off (and the reason why it was cut off, i.e., cut by bound, or by 
>> infeasibility )?
>>
>> I think that doing this can be done by writing an event handler or 
>> something like that, but I have not seen a file like that in the 
>> examples that you have.
>>
>> Thanks for your help.
>>
>> -Jose
>
>
>
> _______________________________________________
> 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/mailman/private/scip/attachments/20120518/2104bcae/attachment.html