[SCIP] Detect a feasible LP node with infeasible values

Gerald Gamrath gamrath at zib.de
Thu Feb 18 10:31:28 CET 2016


Dear Wen-Yang,

as long as there are unfixed integer variables, you are allowed to just 
return INFEASIBLE in your CONSENFOLP callback, because SCIP will then 
branch on one of the unfixed integer variables. If they are all fixed, 
your constraint handler may still return INFEASIBLE and register 
external branching candidates (e.g., for spatial branching). However, if 
you just return INFEASIBLE without any branching candidates available, 
SCIP will have no chance to resolve this infeasibility. Therefore, you 
should return SCIP_CUTOFF, meaning that the node with its current 
variable bounds (or fixings) contains no feasible solution.

The method you are looking for is SCIPgetNPseudoBranchCands(). This 
returns the number of unfixed integer variables (the candidates for 
pseudo branching, which is applied if there are no LP branching 
candidates).  SCIPgetNLPBranchCands() returns those LP branching 
candidates, which are just all integer variables with fractional value 
in the LP solution.

If you return SCIP_CUTOFF instead of SCIP_INFEASIBLE if there are no 
pseudo candidates, then SCIP will be able to solve the problem 
correctly. However, there are many ways how you can improve the solving 
behaviour:

1) In your current implementation, if a variable is locally fixed to a 
forbidden value, SCIP will just branch out all the other integer 
variables and whenever they are all fixed, you return SCIP_CUTOFF, so 
that the leaves of this subtree can finally be cut off. An easy fix for 
this would be to return SCIP_CUTOFF if the variable triggering the 
infeasibility is already fixed to the integer value.

2) In general, CONSENFOLP should try to resolve the infeasibility by 
branching or adding constraints, just returning SCIP_INFEASIBLE should 
be the last resort (or the starting point of your implementation since 
it already leads to a correct solver behaviour). In your case, if you 
detect that an unfixed variable has a forbidden LP value, you should 
probably branch on that variable, removing that infeasible value from 
both child node domains.

3) Finally, I would suggest to also implement the propagation callback 
of your constraint handler. This could detect infeasibility of a node if 
a variable is fixed to a forbidden value already before the node LP is 
solved. Moreover, it could tighten the variable domains, e.g. if one of 
the end points of the domain is forbidden.

Probably, you had already planned to implement at least some of that, 
but perhaps this gives you some new ideas.

Best,
Gerald

Am 18.02.2016 um 00:15 schrieb Wen-Yang Ku:
> Dear SCIP Community,
>
> I have developed a constraint handler to ensure that an integer 
> variable does not take a list of specific integer values as its 
> solution. In the CONSENFOLP function, I first check if the LP solution 
> of this integer variable is on the list. If it's on the list, then I 
> return SCIP_INFEASIBLE. However sometimes I will run into a situation: 
> "ERROR: LP was solved, all integers fixed, some constraint still 
> infeasible, but no branching could be created!". I looked at solver.c 
> and it seems that a feasible LP solution with all integer values fixed 
> has to be feasible. So I am wondering if there is a way to detect such 
> a LP node so I can cut it off and avoid the error. I currently tried 
> to detect such nodes with SCIPgetNLPBranchCands(scip)==0 and count the 
> number of the variables that are fixed to integers, but it gives me 
> more nodes than what I expected.
>
> Thank you very much.
>
> Best regards,
> Wen-Yang
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip



More information about the Scip mailing list