[Cbc] Are heuristics required to respect the bounds of the current node?

[Thomas Schoenemann]

Dear John,

thank you for the quick reply! In the meantime I found out that my heuristic 
may have violated the _initial_ bounds of the problem. Moreover, I found it 
gives better results if I respect the constraints of the current node. If I 
encounter any problems in the future, I will certainly get back to your mail 
and do the proposed tests.

But there is one point I would still like to know: what am I to make of the 
message "on closer look the node is infeasible" that appears whenever I return 
a solution that is not actually useful? Is this node really pruned away?

Best regards,
  Thomas

Am Donnerstag, 30. September 2010 15:02:16 schrieb John Forrest:
> Thomas,
>
> A solution does not have to respect current bounds.  For example RINS
> can easily generate a solution violating current bounds.
>
> The code in setBestSolution picks up a copy of continuousSolver_ (which
> is solver at root node after initial preprocessing) and uses that.
>
> In your heuristic, try cloning the continuousSolver, fixing variables
> and see if that is feasible.  There may be a quirk in the preprocessing
> that throws off your specialized heuristic.
>
> John Forrest
>
> On Thu, 2010-09-30 at 14:11 +0200, Thomas Schoenemann wrote:
> > Dear all,
> >
> > I have written my own heuristic for a specialized problem I have, and I
> > believe it returns feasible solutions. However, I found out that some of
> > them are not consistent with the variable bounds I get by calling
> > getCbcColLower() and getCbcColUpper(). Now, if I let my solution() method
> > return 1 in this case, CBC prints a message that the node is infeasible.
> > If I call setBestSolution() instead, I get a message that I am trying to
> > save an infeasible solution.
> >
> > Of course I cannot be 100% certain that the error is not on my side. But
> > can anyone tell me if the current release (Cbc-2.5.0) should indeed
> > behave this way? That is, will it (incorrectly) cut away the node if
> > solution() returns 1 because it thinks the node is infeasible? And is
> > there a reason (i.e. the current software design does not allow a
> > modification of the code) why one should not save a good solution that is
> > inconsistent with the current branch?
> >
> > Best regards,
> >    Thomas Schoenemann
> >
> > _______________________________________________
> > Cbc mailing list
> > Cbc at list.coin-or.org
> > http://list.coin-or.org/mailman/listinfo/cbc
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc