[Cbc] CLI-like solve with API

[Matthew Gidden]

Hi John,




On Mon, Jul 28, 2014 at 1:24 PM, John Forrest <john.forrest at fastercoin.com>
wrote:

>  Matthew,
>
> I get identical results using driver4.cpp and cbc executable - if you
> don't then maybe I can track it down.
>
I can confirm this to be the case. I've updated my in-library timing to use
CoinCpuTime(), and have confirmed the longer run times with my application.

>
> In your example it would be OsiClpSolverInterface iface and maybe there is
> some subtle difference between reading an mps file and ConstructModel.
>
I've spent some time looking into this and I'm really surprised that this
is the cause of the time difference. If I use an OsiCbcSolverInterface and
pass CbcMain0/1 my model pointer, I see the 2-3x slow down factor I
described earlier. If a use an OsiClpSolverInterface and create a CbcModel
as in the example, I see the exact same answer as the CLI, less a ~0.1s
overhead (which I attribute to the time difference of reading and MPS
file). Definitely good to know about, but unexpected (for me), behavior!

Thanks again,
Matt

>
>
> John Forrest
>
> On 28/07/14 18:43, Matthew Gidden wrote:
>
> Hi all,
>
>  I just wanted to report back. I've been hunting for the actual main
> function used by the CLI, and as best I can tell it's in CoinSolve.cpp. It
> doesn't appear that there's anything extra going on between CbcMain0 and
> CbcMain1. Accordingly, it's unclear to me why a call to `cbc` from the
> command line returns a solution consistently faster than using the API by a
> factor of ~2-3 for smallish problems. To be clear, I do the following:
>
>  OsiCbcSolverInterface iface;
>> ConstructModel(iface);
>
> int argc = 3;
>> const char *argv[] = {"exchange","-solve","-quit"};
>
> CbcMain0(*iface->getModelPtr());
>> CbcMain1(argc, argv, *iface->getModelPtr(), callBack);
>
>
>  I'm going to leave this for now (unless someone has a clear idea as to
> what the difference may be). Using CbcMain0/1 provides me a substantial
> speed up (3 orders of magnitude) over naively calling branchAndBound, as
> one might expect.
>
>  I would still be very interested in any documentation regarding the
> heuristics, cuts, branching strategies, etc. used in CbcMain1 (again, 8k+
> lines of code is burdensome to investigate). I would also be very
> interested if anyone has any open source drivers that do something like
> CbcMain1 (i.e., apply 'generally good' heuristics, cuts, etc.) but
> maintains the unsolved model in order to provide user-specified, additional
> options.
>
>  Again, I apologize if this is old hat for the community; I'd also like
> to specifically thank John and Rolf for assisting.
>
>  Cheers,
>
>
>
> On Sun, Jul 27, 2014 at 10:02 AM, Matthew Gidden <gidden at wisc.edu> wrote:
>
>> Hi John,
>>
>>
>>
>>
>>  On Sat, Jul 26, 2014 at 1:45 PM, John Forrest <
>> john.forrest at fastercoin.com> wrote:
>>
>>>  Matthew,
>>>
>>> Look at driver4.cpp in Cbc/examples.
>>>
>>  I'm playing around with this right now. Just using CbcMain0 and
>> CbcMain1 get's within an order of magnitude of the CLI execution. I'll keep
>> at it. Thanks for the input!
>>
>>>  You could easily turn some of that into your SolveModelLikeCli (with
>>> optional string of parameters).
>>>
>>> John Forrest
>>>
>>>
>>> On 26/07/14 00:06, Matthew Gidden wrote:
>>>
>>>  Hi all,
>>>
>>>  I've discovered that the cbc CLI does a pretty good job at solving my
>>> class of problems.  In short, I'm curious if there's a way to get that rich
>>> functionality at the API level. Ideally, I'd like to do something like the
>>> following:
>>>
>>>  model = ConstructModel();
>>>> SolveModelLikeCLI(model);
>>>
>>>
>>>  It looks like the implementation is one long function (cbcMain1 is 8k+
>>> lines) and would be incredibly difficult to cherry-pick implementation from
>>> it. I've scoured the API docs and haven't found anything that looks
>>> promising. Alternatively, is there a listing of all the heuristics, cuts,
>>> branching strategies, etc., used by the default CLI?
>>>
>>>  Sorry if this is an obvious question; I was hoping to leverage the
>>> features already implemented before reimplementing something myself.
>>>
>>>  --
>>> Matthew Gidden
>>> Ph.D. Candidate, Nuclear Engineering
>>> The University of Wisconsin -- Madison
>>> Ph. 225.892.3192
>>>
>>>
>>>   _______________________________________________
>>> 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
>>>
>>>
>>
>>
>>  --
>> Matthew Gidden
>> Ph.D. Candidate, Nuclear Engineering
>> The University of Wisconsin -- Madison
>> Ph. 225.892.3192
>>
>
>
>
>  --
> Matthew Gidden
> Ph.D. Candidate, Nuclear Engineering
> The University of Wisconsin -- Madison
> Ph. 225.892.3192
>
>
>


-- 
Matthew Gidden
Ph.D. Candidate, Nuclear Engineering
The University of Wisconsin -- Madison
Ph. 225.892.3192
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20140728/eccc6cf7/attachment.html>