[Cbc] Pruning decisions in Cbc with Clp as LP solver

[Aleksandr M. Kazachkov]

Hi all,

I am trying to understand better one of the cases in which nodes are pruned
in Cbc (version 2.9.9) during branch-and-bound, when using Clp as the LP
solver. What confuses me is that at some point (more details below) there
is a call to OsiClpSolverInterface::resolve that results in a designation
that the subproblem is primal infeasible when it is not (as confirmed by a
call to initialSolve and manually checking it on my toy 4-dimensional
example). My question is: in which cases will this call to resolve lead to
an infeasible designation? I think (but am not sure) that I am seeing this
happen when the node is being pruned by integrality or by bound (not just
by infeasibility).

=== Details ===
When the "node" event is reached (at line 16906 of CbcModel.cpp), as the
comment in the code there states, sometimes newNode is null when the node
is found to be infeasible. This "infeasibility" sometimes is determined
from the call to "solveWithCuts" (at line 16491 in CbcModel.cpp), in which
eventually (at line 14411), the Clp resolve is called. I know that when
called from Cbc (when OsiDoInBranchAndCut is set to true), the resolve will
act differently, but I do not understand exactly in what way. Am I correct
that the resolve may say "primal infeasible" (problemStatus_ = 1 in the
ClpModel) either when the subproblem: (1) is indeed infeasible, (2) will be
pruned by integrality, or (3) will be pruned by bound?

A small (4-dimensional) lp file is attached that can be used for testing.
Though it may happen in other cases with this file, for sure I encounter
the situation when using full strong branching (CbcBranchDefaultDecision
for the branching direction choice, OsiChooseStrong for deciding on which
variable to branch on, and CbcCompareObjective for picking the next node to
explore from the tree). I can send the tree I get if it helps with
answering my question.

===
Thank you in advance for any help or pointers to the right place in the
documentation,
Aleksandr Kazachkov

P.S. When newNode is deleted (when anyAction = -2 at line 16854 of
CbcModel.cpp), currentNode_ is not deleted and points to the same memory as
newNode. I suppose this may be why the documentation says "be careful" when
calling currentNode(). But it may be worth setting currentNode_ to 0x0 as
well, as we indeed have to be careful to not access (from the event
handler) the memory pointed to by currentNode_ when that memory has been
freed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20170726/00019381/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: temp3.lp
Type: application/octet-stream
Size: 355 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20170726/00019381/attachment.obj>