[Cbc] Intermediate results via CbcModel.bestSolution()

[acw at ascent.com]

The quoted conversation below suggests that up until recently we've simply 
been dodging bullets, submitting problems that don't happen to trigger 
compression; or perhaps in our recent upgrade some of the things we 
changed caused compression to occur where it hadn't up until now.

Our present code is very simple, following the outlines of some of the 
example drivers in the Cbc/examples directory.  Once the model has been 
set up, we call CbcMain0 and then CbcMain1.  By the time we call 
CbcModel->solver()->getColSolution(), the solution has been decompressed 
and everything is good.  So there's no visible messing about with 
CglPreProcess, and at the moment we don't know how to do what Dr. Forrest 
suggests.  Any additional advice or code samples would be welcome.



From:
Haroldo Santos <haroldo.santos at gmail.com>
To:
John Forrest <john.forrest at fastercoin.com>
Cc:
"cbc at list.coin-or.org" <cbc at list.coin-or.org>
Date:
07/15/2010 01:36 PM
Subject:
Re: [Cbc] Intermediate results via CbcModel.bestSolution()



Hi Forrest,

originalColumns() returns a primal solution ? indexes to map to the
original columns ?

On Thu, Jul 15, 2010 at 1:39 PM, John Forrest
<john.forrest at fastercoin.com> wrote:
> bestSolution() never decompressed solution so you just must have been
> lucky.
>
> If you did CglPreProcess and pass a pointer to that in to the handler
> using bestSolution() then you can pick up originalColumns() and put the
> solution back into the original model.
>
> John Forrest
>
>
>
> On Thu, 2010-07-15 at 11:27 -0400, acw at ascent.com wrote:
>> In our application, we pose biggish problems to Cbc, which then goes
>> off and spends quite a while solving them.  Even before we get the
>> optimal solution, we can make use of any solutions Cbc finds along the
>> way.
>>
>> So, during the solution process, when we see that Cbc has improved its
>> best result, we query the CbcModel using bestSolution().
>>
>> Recently we've started encountering a problem where the returned
>> solution is much shorter than expected.  Looking at the number of
>> columns in the solution makes us suspect that we are seeing solutions
>> to the processed model, and not to the original one.  That is, Cbc is
>> boiling the problem down to a smaller, equivalent problem, and solving
>> that; when it's completely finished it inverts the transformation to
>> give a solution to the original problem.  But if we interrupt it, we
>> find an intermediate solution to the transformed problem, not the
>> original.
>>
>> This makes a certain amount of sense, but it didn't use to happen.  In
>> a previous Cbc version, either the model was not compressed in the
>> same way, or bestSolution() inverted the compression regardless of
>> whether the solution was complete.
>>
>> Is this change in behavior intentional?  If so, does there remain any
>> supported way to extract an intermediate solution to the problem as
>> posed?
>>
>> Thank you; our experience with Cbc has been overwhelmingly positive,
>> and we're sure there's an easy solution to this glitch as there have
>> been for every problem we've encountered in the past.
>> _______________________________________________
>> 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
>



-- 
=============================================================
Haroldo Gambini Santos
Computing Department - Universidade Federal de Ouro Preto - UFOP
email: haroldo [at ] iceb.ufop.br
home/research page: http://www.iceb.ufop.br/decom/prof/haroldo/

"Computer science is no more about computers than astronomy
is about telescopes." Edsger Dijkstra


_______________________________________________
Cbc mailing list
Cbc at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/cbc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/cbc/attachments/20100715/b90bfddc/attachment.html