[Cbc] Cuts generation when using Xpress
Ted Ralphs
ted at lehigh.edu
Thu Jul 1 19:14:43 EDT 2010
Thomas,
Now that I'm looking at your config.log and I can see how you've built
Cbc, it's clear that what's happening is surely not what you're
looking for, but I'm still a little mystified by the behavior you are
apparently seeing. In order to use any solver other than Clp as the
default LP solver, you would need to configure with the option
"--with-cbc-generic=solver_name". However, I was just looking at the
configure options and I see that the only solvers that configure knows
about right now are clp, dylp, and glpk. Thus, even if you were to
pass the right configure options for using Xpress, it wouldn't work as
things are at the moment. In the code itself, it looks as though there
are a few more options that Cbc knows about (CPLEX and Mosek as well),
but these additional options appear to be untested.
I think it would not be *too* difficult to enable the possibility of
using Xpress as the default LP solver. This means we could probably
get the code to build and link with Xpress, but it's not clear this
would work entirely correctly or have all the bells and whistles of
Cbc with Clp. In fact, it would surely be missing some of them. As for
what's happening right now, it looks to me like specifying the
location of Xpress at configure time should not, in principle, make
any difference to the way Cbc behaves and in my testing, this does in
fact seem to be the case. It is simply using Clp as the LP solver as
usual and the results are the same either way.
So, can you try building Cbc with no arguments to configure and
compare the results you see using that version of Cbc with the one you
have built with Xpress? If there are differences, then that would give
us some clues. If you want, I can try to get Cbc working with Xpress
as the LP solver. Let me know if this is something you would like to
try.
Cheers,
Ted
On Thu, Jul 1, 2010 at 1:49 PM, Thomas Schoenemann <tosch at maths.lth.se> wrote:
> Dear Ted,
>
> The config.log is attached. I have now also run the unit test, here is
> how it ends:
>
>
> -------------------------------------------------------------------
>
> Testing CglGomory with OsiXprSolverInterface
>
> There are 2 gomory cuts
> There are 4 gomory cuts
> There are 4 gomory cuts
> There are 2 gomory cuts
> There are 4 gomory cuts
> There are 4 gomory cuts
> There are 1 gomory cuts
> There are 2 gomory cuts
> There are 2 gomory cuts
> There are 1 gomory cuts
> There are 2 gomory cuts
> There are 2 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> There are 1 gomory cuts
> Coin0008I P0033 read with 0 errors
>
> XPRS0000
> XPRS0000 Reading Problem Prob2
> XPRS0000 Problem Statistics
> XPRS0000 16 ( 0 spare) rows
> XPRS0000 33 ( 0 spare) structural columns
> XPRS0000 98 ( 0 spare) non-zero elements
> XPRS0000 Global Statistics
> XPRS0000 0 entities 0 sets 0 set members
> XPRS0000 Presolved problem has: 14 rows 24 cols 62 non-zeros
> XPRS0000
> XPRS0000 Its Obj Value S Ninf Nneg Sum Inf Time
> XPRS0000 0 .000000 D 1 0 28.894531 0
> XPRS0000 15 2520.571739 P 0 0 .000000 0
> XPRS0000 15 2520.571739 P 0 0 .000000 0
> XPRS0000 Uncrunching matrix
> XPRS0000 15 2520.571739 P 0 0 .000000 0
> XPRS0000 Optimal solution found
> Initial LP value: 0
> lt-unitTest: CglGomoryTest.cpp:1466: void CglGomoryUnitTest(const
> OsiSolverInterface*, std::string): Assertion `eq(lpRelaxBefore,
> 2520.5717391304347)' failed.
>
> -------------------------------------------
>
> Interestingly, in this case cuts are found, so maybe it IS a problem
> specific effect. I am using Cbc 2.4.0, but in this case I was not using
> Cbc at all. Instead, I have only created an OsiXpr interface, solved the
> linear program and then passed it to (e.g.) a CglGomoryCut object. If I
> do this with a OsiClpInterface, everything is fine. Calling Cbc and
> setting the node-limit to 0 is considerably slower, I suspect some kind
> of strong branching is done even though there will never be a braching
> decision to make.
>
> Best regards,
> Thomas
>
>
>
> On 07/01/2010 05:31 PM, Ted Ralphs wrote:
>> Did you try running the Cgl unit test after building? To do so, go
>> into the Cgl subdirectory in the directory in which you did the build
>> and just do "make test". You could also try running Cbc's unit test by
>> doing "make test" in the root of the directory in which you did the
>> build. I do have access to Xpress, so I will also try. I have a
>> feeling that something went wrong in the build process. It might be
>> helpful if you could send me the file config.log from the directory in
>> which you did the build and the output from the unit tests.
>>
>> Cheers,
>>
>> Ted
>>
>> On Thu, Jul 1, 2010 at 6:51 AM, Thomas Schoenemann <tosch at maths.lth.se> wrote:
>>
>>> Dear Lou and Ted,
>>>
>>> thank you very much for your suggestions. I had compiled Cbc without telling
>>> it about Xpress, then later manually compiled OsiXpr.
>>>
>>> So I now reran the configure-script with the --with-xpress-lib and --with-
>>> xpress-incdir options, and compiled everything anew. However, the result is
>>> the same: the cut generators do not find cuts when I use Xpress, but they find
>>> lots of cuts when I use Clp. Unfortunately, for this particular problem Xpress
>>> has proven to be much more suitable.
>>>
>>> I could send you the source code if you think it helps. But I really do not
>>> think that this behaviour is specific to the problem I am solving. And you
>>> would of course need to acquire Xpress for yourself.
>>>
>>> Please let me know how you want to proceed.
>>>
>>> Best,
>>> Thomas
>>>
>>>
>>> Am Mittwoch, 30. Juni 2010 18:27:55 schrieb Lou Hafer:
>>>
>>>> Thomas,
>>>>
>>>> One of the first things you might try is the Cgl unit test.
>>>> (Cgl/Cgl/test/unitTest.cpp). Cgl/Cgl/configure checks for presence of
>>>> OsiXpr so it should be automagically included if it's present. If you see
>>>> no cuts from the unit test, something's seriously wrong.
>>>>
>>>> The other thing to say is that at present cbc is tightly tied to
>>>> features that are only present in clp (i.e., not present in the standard
>>>> Osi API). It's hard to say just what's going wrong without code. As Ted
>>>> said --- is it possible to provide your driver and information on how
>>>> you're building the code?
>>>>
>>>> Lou
>>>>
>>>> _______________________________________________
>>>> Cbc mailing list
>>>> Cbc at list.coin-or.org
>>>> http://list.coin-or.org/mailman/listinfo/cbc
>>>>
>>>
>>>
>>
>>
>>
>
>
--
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted
More information about the Cbc
mailing list