Originally posted by: SystemAdmin

[Sylvain said:]

I noticed a strange behaviour in my program while developping a specific MIP Branching Callback to solve my problem with Cplex.

Indeed, when I get the bounds of a variable in the callback using getUB() and getLB(), I sometimes get 0 for the upperbound and 1 for the lower bound for a binary variable (Always the same).

It only happen after the binary variable has been fixed in a previous node. So, one of the bounds is inconsistent.

The continuous relaxation is solved previously to this callback with no problems (it is found feasible).

I noticed that this strange behaviour disappears if I don't create any branch (method makeBranch()) in the callback.

Does anyone have any idea that could help me understand what is wrong here ?

PS: I also noticed that indicator constraints do not work properly when I am using this callback. Probably because of this inconsistent bounds...
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[jgregory said:]

It would probably be helpful to know which version of CPLEX you are using - 10.0, 10.1, 10.2, or perhaps 11.0? 
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[Sylvain said:]

Of course. It's version Cplex version 10.1.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[jgregory said:]

Well, after some discussion here, it probably doesn't matter which recent CPLEX version is being used after all, although concreteness never hurts.

Before the branching callback is called, CPLEX performs its own variable selection to pick a variable, for the purpose of course to let the user override this choice.  As Branch & Cut has evolved over the years, more and more side-effects occur, making it difficult to place a given callback in a spot where the behavior is clearly defined.  In the case of branch selection, the act of CPLEX picking a candidate branching variable may result in a node itself being determined to be infeasible.  In that case, contradictory bounds on the variable that demonstrated the infeasibility might be placed, in order that the node be pruned in a step soon to follow.  This may happen at any point in the tree.  It's very unlikely the condition you are seeing is a misbehavior.

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[Sylvain said:]

I just found out where was my mistake.
I was using the bounds of variables to determine which one I choose to branch on.
This is not correct as some variables might have been removed during the presolve (such as "ImpliedFeasible" variables).
So I needed to use the function getFeasibility() instead to determine correctly whether a variable is a candidate for branching or not.
#CPLEXOptimizers
#DecisionOptimization