[Cbc] modifying a CbcModel after solve?

[John Forrest]

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 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/20140526/245a8b3c/attachment.html>