[Cbc] CoinModel Equality?

[Matthew Gidden]

Hi John, all,

I've finally got my testing plumbing finished and am actually trying to
compare Models. I'm running into the problem that
a) there is no member function for OsiSolverInterface to return access to a
CoinModel
b) Models don't actually from CoinModel (e.g.,
ClpSimplex->ClpModel-/>CoinModel)

I'll do my best to explain my problem and wait for advice/clarification
from the list.

I have a factory method that returns a pointer to an OsiSolverInterface. I
then create an instance of a problem using the interface, solve it, and
interpret the solution. My goal is to unit test the model creation process.

In the following example, the interface is named iface, CoinPackedMatrix
(m),  and the associated upper/lower bounds are vectors. Is this the best
way to try to compare models? (FYI -- I assume not, because it results in a
seg fault)

  CoinModel model(nrows, ncols, &m, &row_lbs[0], &row_ubs[0],
>                   &col_lbs[0], &col_ubs[0], &obj_coeffs[0]);
>   ClpSimplex* compare =
> dynamic_cast<OsiClpSolverInterface*>(iface)->getModelPtr();
>   EXPECT_EQ(0, model.differentModel(*compare->createCoinModel(), true));


You can see the entire (long) testing process here:
https://github.com/gidden/cyclus/blob/lpsolver/tests/prog_translator_tests.cc

Thank you very much in advance!



On Thu, Feb 13, 2014 at 11:44 AM, Matthew Gidden <gidden at wisc.edu> wrote:

> Awesome, thank you, John.
>
>
> On Thu, Feb 13, 2014 at 11:43 AM, John Forrest <
> john.forrest at fastercoin.com> wrote:
>
>>  Matthew,
>>
>> There is a CoinModel::differentModel which should do what you want.
>> There is a default tolerance test for two values being same - if this isn't
>> good enough then it would be easy to pass in a tolerance test to one of the
>> CoinModels.
>>
>> John Forrest
>>
>> On 06/02/14 19:42, Matthew Gidden wrote:
>>
>> Great, thanks for your response, Miles!
>>
>>
>> On Thu, Feb 6, 2014 at 12:27 PM, Miles Lubin <miles.lubin at gmail.com>wrote:
>>
>>> Hi Matthew,
>>>
>>>  CoinModel can be used to store an LP/MIP instance, but I don't believe
>>> there are any comparison methods. You'll likely have to manually iterate
>>> through the problem data to compare entry by entry, using whatever
>>> floating-point comparison tolerance is appropriate. I would also suggest
>>> building your infrastructure around a solver-independent interface like
>>> OSI, because it's always valuable to be able to compare the performance of
>>> different solvers. Any academic publication would be remiss to only use one
>>> open-source MIP solver when making claims about time to solve a particular
>>> problem.
>>>
>>>  Best,
>>> Miles
>>>
>>>
>>>  On Thu, Feb 6, 2014 at 12:51 PM, Matthew Gidden <gidden at wisc.edu>wrote:
>>>
>>>>  Hi all,
>>>>
>>>>  First time caller, long time listener. I'm gearing up the portion of
>>>> my research in which I'll be using and comparing simplex and branch-and-cut
>>>> solvers versus some naive solvers in our simulation environment [1]. We
>>>> require a permissive, open source license (for compatibility with our own -
>>>> BSD 3-clause), so the COIN suite was a natural fit.
>>>>
>>>>  To the meat of my question:
>>>> I've written a high-level API for myself and other devs to use to
>>>> describe an problem instance in part of our simulation framework. I would
>>>> like to be able to unit test it such that a problem instance it describes
>>>> is equivalent to some known problem instance (read in through MPS, for
>>>> example). My initial thought was to compare configured CoinModels (i.e.,
>>>> builders). Is there an easy way to compare them? Is this the best approach?
>>>>
>>>>  I look forward to your response, thanks!
>>>>
>>>>  [1] http://fuelcycle.org/
>>>>
>>>>  --
>>>> Matthew Gidden
>>>> Ph.D. Candidate, Nuclear Engineering
>>>> The University of Wisconsin -- Madison
>>>> Ph. 225.892.3192
>>>>
>>>>  _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20140216/60df9d64/attachment.html>