<div dir="ltr">Hi all,<div><br></div><div>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).</div><div><br></div><div>=== Details ===</div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>===</div><div>Thank you in advance for any help or pointers to the right place in the documentation,</div><div>Aleksandr Kazachkov</div><div><br></div><div>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.</div></div>