[Scip] Unexpected use of function scip_execps

[Gregor Hendel]

Dear Marko and list,

Am 02.04.2015 um 12:54 schrieb Horváth Markó:
> Dear All,
>
> I'm using scip 3.1.1 with soplex 2.0.1. (on 1 thread) through C++. I'm 
> deailing with a branch-and-price procedure for a MILP. The problem 
> contains continuous and binary variables where the binary variables 
> have lazy upper bound (the minimization problem has a set partition 
> structure so an LP solution should respect these bounds).
>
> I have made a pricer and a branching rule, of course, and I'm 
> expecting SCIP to call my function scip_execlp. And SCIP does it 
> usually, but sometimes calls the function scip_execps, and I can't 
> find its reason.
The pseudo solution gets enforced for two main reasons: Either there are 
unresolved numerical troubles in the node LP solution. The focus node is 
then "un-LP-ized" by setting the tree->focusnodehaslp to FALSE via 
SCIPsetFocusNodeLP().
You can check whether this is the case by the public method 
SCIPhasFocusNodeLP() from inside the execps-callback of your branching rule.

The second reason for using pseudo-branching is the use of custom 
branching priorities for the variables. Concretely, if an unfixed 
variable with an integral LP solution value (ie. a pseudo candidate) has 
a higher branching priority than the prioritized fractional LP candidate 
variable, pseudo-branching is executed instead. Do you use branching 
priorities for your variables?
>
> Okay, it's clear from the documentation that SCIP calls scip_execps if 
> 'an integral solution violates one or more constraints and this 
> infeasibility could not be resolved...', but what does it mean? Hasn't 
> SCIP solved the LP in the focused node? I have made an event handler 
> to check the solving steps and I've got the following output:
> /...//
> //[nodefocused] node 11 has been focused and is now the focus node//
> //[firstlpsolved] initial LP of node 11 was solved//
> //[lpsolved] LP of node 11 was completely solved with cut & price//
> //[nodebranched] the focus node 11 has been solved by branching//
> //.../
> so it means for me that the LP has been solved. But the branching 
> procedure used the function scip_execps instead of scip_execlp, and I 
> still don't see the reason. Can you explain it me?
>
> On the other hand, I wanted to check if a solution violates some 
> constraints (something like SCIPchecksol). I can get the variables of 
> a constraint, but I haven't found any procedure to get the coefficient 
> of a variable in a given constraint. Is there an easy way to get it?
Please note that in general, there is no 1-to-1 correspondence between a 
constraint and a row of the LP relaxation, just take the integral 
constraints as an example. SCIP itself does not check individual 
constraints, but delegates
this task to the constraint handlers, which treat their constraints 
individually. If you have only linear-type constraints (i.e, either 
linear constraints or specializations such as knapsacks or varbound
constraints), there mostly exist library methods to access the necessary 
data, just take a look at the headers of
cons_linear.h, cons_knapsack.h etc, to perform a customized solution check.

Kind regards,
Gregor


>
> Best Regards,
> Markó Horváth
>
>
> _______________________________________________
> 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/20150407/7dfff7c7/attachment.html>