[Cbc] modifying a CbcModel after solve?

[Miles Lubin]

Hi John,

That approach is certainly feasible, although I'd like keep in line with
other commercial and open-source interfaces and make these modification
routines "just work". What could be done is to always make a copy of the
model before a solve, pick out the solution information, and throw away the
dirty solved model. Unless there are any objections to the overhead of
temporarily having multiple copies of the model around, I'll play around
with this approach.

Thanks,
Miles


On Mon, May 26, 2014 at 11:57 AM, John Forrest
<john.forrest at fastercoin.com>wrote:

>  Miles,
>
> Having solved a model the CbcModel is much modified e.g. average change in
> objective when branching on integer variables, value of best possible
> solution etc.  Also a copy of solver at various times has been solved.
>
> What is wrong with
>
> Cbc_Model * baseModel = Cbc_newModel();
>
> do what you like to build most of model
>
> while (wanted) {
>   Cbc_Model * model = Cbc_clone(baseModel);
>
>   adjust model
>
>   Cbc_solve(model);
>
>   use results
>
>   Cbc_deleteModel(model);
> }
>
> Cbc_deleteModel(baseModel);
>
> If this is approximately what you want then it can be fine tuned.
>
> John Forrest
>
>
>
> On 26/05/14 02:35, Miles Lubin wrote:
>
> Hi all,
>
>  I'm looking at supporting modification of the problem data after solve
> in the C interface and have come across some surprising behavior.
>
>  After solving using a CbcModel (using CbcMain1), the column lower bounds
> (from CbcModel::getColLower) are changed to equal the value of the optimal
> solution. I.e., a binary variable set at 1 in the optimal solution will
> have a reported lower bound of 1. I assume this is because the bounds are
> returned from the internal Clp model.
>
>  Similarly, calling CbcModel::solver()->setColLower() after solve to
> modify bounds doesn't seem to have any effect on subsequent resolves (again
> using CbcMain1).
>
>  Is there a proper way to access and modify the original problem data
> after a solve to avoid recreating the model from scratch? If not, I'll
> simply not expose this functionality in the C interface. Obviously one
> shouldn't expect to efficiently hot-start the next MIP solve, but being
> able to modify a model could be convenient for the user when solving a
> sequence of related MIPs.
>
>  Thanks,
> Miles
>
>
> _______________________________________________
> Cbc mailing listCbc at list.coin-or.orghttp://list.coin-or.org/mailman/listinfo/cbc
>
>
>
> _______________________________________________
> 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/20140528/bad63e88/attachment.html>