<div dir="ltr"><div>Thank you, I will try next release.</div><div><br></div><div>Note that it does not always happen : in the example I provided before, activating preprocess allows to get valid solution although max time stopped optimization.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 17 févr. 2020 à 11:42, Stefan Vigerske <<a href="mailto:svigerske@gams.com">svigerske@gams.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I reverted this in stable/2.10, too, so should also be in the next release.<br>
<br>
Stefan<br>
<br>
On 2/17/20 11:27 AM, John Forrest wrote:<br>
> Nicolas,<br>
> <br>
> The following code got into 2.10.4 when doing initial solve. This meant <br>
> that if the branch and bound code stopped on max time, then all cleanup <br>
> solves after would stop without proper finishing and so give wrong results.<br>
> <br>
> #ifdef COIN_HAS_CLP<br>
> OsiClpSolverInterface *clpSolver<br>
> = dynamic_cast< OsiClpSolverInterface * >(solver_);<br>
> if (clpSolver) {<br>
> double maxTime = <br>
> dblParam_[CbcMaximumSeconds]-dblParam_[CbcStartSeconds];<br>
> if ((moreSpecialOptions_&131072)==0)<br>
> clpSolver->getModelPtr()->setMaximumSeconds(maxTime);<br>
> else<br>
> clpSolver->getModelPtr()->setMaximumWallSeconds(maxTime);<br>
> }<br>
> #endif<br>
> <br>
> That code has been taken out in master/trunk - so 2.11 should be good.<br>
> <br>
> John Forrest<br>
> <br>
> <br>
> On 10/02/2020 10:17, Nicolas Cbc wrote:<br>
>> Hi everyone,<br>
>><br>
>> I am still having problem with max time limit when preprocess is off <br>
>> even with 2.10.4 version.<br>
>> I am solving mip problem using binary found on bintray <br>
>> (Cbc-2.10.4-win32-msvc15).<br>
>><br>
>> Sometimes, cbc reaches max time limit but does not return the best <br>
>> solution found providing uncorrect data.<br>
>> I attached the mps file and three log files.<br>
>><br>
>> Without preprocessing, I get this at the end of log with 2.10.4 (I <br>
>> deleted cuts info for readibility) :<br>
>> Cbc0010I After 1300 nodes, 13 on tree, 20305.811 best solution, best <br>
>> possible 20209.422 (19.38 seconds)<br>
>> Cbc0004I Integer solution of 20305.811 found after 61433 iterations <br>
>> and 1334 nodes (19.79 seconds)<br>
>> Cbc0020I Exiting on maximum time<br>
>> Cbc0005I Partial search - best objective 20305.811 (best possible <br>
>> 20209.422), took 61895 iterations and 1362 nodes (20.00 seconds)<br>
>> Cbc0032I Strong branching done 2042 times (14765 iterations), fathomed <br>
>> 76 nodes and fixed 176 variables<br>
>> Cbc0035I Maximum depth 22, 62 variables fixed on reduced cost<br>
>> 0 Obj 17950.691 Primal inf 63.616727 (121) Dual inf 1.5638368e+12 (75)<br>
>> Stopped - objective value 1.7973277e+12<br>
>> Cuts at root node changed objective from 17950.7 to 19760.5<br>
>> ...<br>
>><br>
>> Result - Stopped on time limit<br>
>><br>
>> Objective value: <br>
>> 100000000000000007629769841091887003294964970946560.00000000<br>
>> Lower bound: 20209.422<br>
>> Gap: 4948187144522872794252484886662922505826598912.00<br>
>> Enumerated nodes: 1362<br>
>> Total iterations: 61895<br>
>> Time (CPU seconds): 20.03<br>
>> Time (Wallclock seconds): 20.03<br>
>><br>
>> The objective value and the gap are clearly wrong.<br>
>> The log indicates clearly that cbc has found an integer solution of <br>
>> 20305.811.<br>
>><br>
>><br>
>> With 2.8.13 (or if I switch on preprocessing with 2.10.4), I get <br>
>> correct data :<br>
>> Cbc0010I After 2400 nodes, 11 on tree, 20305.811 best solution, best <br>
>> possible 19652.01 (19.66 seconds)<br>
>> Cbc0020I Exiting on maximum time<br>
>> Cbc0005I Partial search - best objective 20305.811 (best possible <br>
>> 19652.01), took 69811 iterations and 2442 nodes (20.00 seconds)<br>
>> Cbc0032I Strong branching done 3234 times (22229 iterations), fathomed <br>
>> 292 nodes and fixed 234 variables<br>
>> Cbc0035I Maximum depth 25, 111 variables fixed on reduced cost<br>
>> Cuts at root node changed objective from 17950.7 to 19638.7<br>
>> ...<br>
>><br>
>> Result - Stopped on time limit<br>
>><br>
>> Objective value: 20305.81106305<br>
>> Lower bound: 19652.010<br>
>> Gap: 0.03<br>
>> Enumerated nodes: 2442<br>
>> Total iterations: 69811<br>
>> Time (CPU seconds): 20.03<br>
>> Time (Wallclock seconds): 20.03<br>
>><br>
>> In this case, everything seems logical for me.<br>
>><br>
>> For me, this issue is a big problem because I always have to set a <br>
>> maximum time for optimization.<br>
>> I am forced to still use 2.8.13 version of cbc with whom I dit not <br>
>> have this issue.<br>
>><br>
>> Nicolas<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Cbc mailing list<br>
>> <a href="mailto:Cbc@list.coin-or.org" target="_blank">Cbc@list.coin-or.org</a><br>
>> <a href="https://list.coin-or.org/mailman/listinfo/cbc" rel="noreferrer" target="_blank">https://list.coin-or.org/mailman/listinfo/cbc</a><br>
>><br>
> <br>
> _______________________________________________<br>
> Cbc mailing list<br>
> <a href="mailto:Cbc@list.coin-or.org" target="_blank">Cbc@list.coin-or.org</a><br>
> <a href="https://list.coin-or.org/mailman/listinfo/cbc" rel="noreferrer" target="_blank">https://list.coin-or.org/mailman/listinfo/cbc</a><br>
<br>
_______________________________________________<br>
Cbc mailing list<br>
<a href="mailto:Cbc@list.coin-or.org" target="_blank">Cbc@list.coin-or.org</a><br>
<a href="https://list.coin-or.org/mailman/listinfo/cbc" rel="noreferrer" target="_blank">https://list.coin-or.org/mailman/listinfo/cbc</a><br>
</blockquote></div>