[Cbc] problem with max time limit

Nicolas Cbc nicolascbccoin at gmail.com
Mon Feb 17 11:34:14 EST 2020


Thank you, I will try next release.

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.

Le lun. 17 févr. 2020 à 11:42, Stefan Vigerske <svigerske at gams.com> a
écrit :

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


More information about the Cbc mailing list