[Cbc] Incorrect solution from Cbc with Clp

Kish Shen kisshen at cisco.com
Fri Dec 7 07:01:38 EST 2007


Hi,

Some follow up and more information to my post last week:

1) The problem is feasible, and Cbc thinks it has found the optimal 
solution, but this solution violate one of the constraint as I 
described. A correct feasible solution (and persumably optimal) is 
returned if I make the changes as described.

2) The code that leads to the incorrect solution first set several hint 
parameters, and then if the problem is a MIP problem, the presolve 
parameters are turned off again. Here is the code fragment

     lpd->lp->Solver->setHintParam(OsiDoDualInInitial, doDual, 
OsiHintDo, NULL);
     lpd->lp->Solver->setHintParam(OsiDoDualInResolve, doDual, 
OsiHintDo, NULL);

     lpd->lp->Solver->setHintParam(OsiDoPresolveInInitial, 
lpd->presolve, OsiHintDo, NULL);
     lpd->lp->Solver->setHintParam(OsiDoPresolveInResolve, 
lpd->presolve, OsiHintDo, NULL);

     switch (lpd->prob_type)
     {
     case PROBLEM_MIP:
     case PROBLEM_FIXEDL:
	/* turn off timeout in CLP (otherwise may cause problems for MIP */
	lpd->lp->Solver->getModelPtr()->setMaximumSeconds(-1);

 >>>>	lpd->lp->Solver->setHintParam(OsiDoPresolveInInitial, false, 
OsiHintDo, NULL);
 >>>>	lpd->lp->Solver->setHintParam(OsiDoPresolveInResolve, false, 
OsiHintDo, NULL);

If the last two lines (which I've highlighted with >>>>) are commented 
out, then a correct solution is returned.

3) I can generate the calls to Cbc/Osi libraries that will produce this 
problem, but as the check for the correctness of the solution is done in 
my host language (ECLiPSe), I am not sure if I can easily translate this 
to the Cbc/Osi calls -- there seems to be some code to check the 
solution in CbcModel, perhaps I can use these?

Thanks and cheers,

Kish

Kish Shen wrote:
> Hi,
> 
> This is actually a follow up to a problem I posted about a couple of 
> weeks ago: a user of our system had some incorrect solutions to his 
> problems, and with John Forrest's help, I was able to solve this problem 
> by updating the trunk branch Cbc that I used, on 9 Nov. This gave 
> correct solutions to our user's existing problems. He has since tried 
> his program with newer data sets, and he has found another problem where 
> one of the constraints of the problem is violated by the solution values 
> returned by Cbc/Clp.
> 
> I ran some tests, and found that this only happen on the Linux, running 
> on 32 bit x86 processors. The violated constraint is as follows:
> 
> cons565:  x225 + x226 + x227 + x228 + x229 + x230 + x231 + x232
>           + x233 = 1
> 
> All the variables are integer variables, and have bounds of 0..1. The 
> constraint is violated because all the solution values for the variables 
> are 0.
> 
> In addition to updating the Cbc I was using, I also made another change 
> to my code, because John suggested that I should not do the linear 
> presolve when solving a MIP problem. To stop the linear presolve, I 
> added the following to my code:
> 
>     lpd->lp->Solver->setHintParam(OsiDoPresolveInInitial, false, 
> OsiHintDo, NULL);
>     lpd->lp->Solver->setHintParam(OsiDoPresolveInResolve, false, 
> OsiHintDo, NULL);
> 
> 
> where lpd->lp->Solver is a OsiClpSolver *, where the problem is loaded 
> into.
> 
> I found that when I removed these two lines, the above problem is solved 
> correctly.
> 
> Any idea why this might be so? If required, I can produce the C/C++ 
> program to reproduce this problem.
> 
> Thanks in advance for any help!
> 
> A different issue I noticed: the above constraint is taken from an lp 
> file for the problem, which is produced after the problem was solved. I 
> noticed that the bounds for the integer variables in this lp file are 
> fixed to their solution values, e.g.
> 
>  0 <= x225 <= 0
>  0 <= x226 <= 0
>  0 <= x227 <= 0
>  0 <= x228 <= 0
>  0 <= x229 <= 0
>  0 <= x230 <= 0
>  0 <= x231 <= 0
>  0 <= x232 <= 0
>  0 <= x233 <= 0
> 
> I know that Cbc does fix the integer variables' bounds to their solution 
> values, but in my code, I explicitly reset the bounds to their original 
> values after solving the problem -- this is to allow the problem to be 
> resolved again, and in the checking for the constraint violation, I also 
> obtain the bounds of the variables, and the bounds return are 0 and 1, 
> rather than the fixed values in the LP file.
> 
> Cheers,
> 
> Kish Shen
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc


More information about the Cbc mailing list