[Cbc] cbc-generic is an illusion

[Thomas Schoenemann]

Hey everyone,

I think this is maybe not the appropriate mailing list, for all I really want 
is the Cgl working with Xpress. I readily believe that Cbc is a very extensive 
project, but I would expect that Cgl is more easily maintained.

Here is what my code is doing:

1. solve an LP-relaxation via OsiXpr
2. create a cut collection and a cut generator, then have it generate cuts 
from the OsiXpr.
3. apply the cuts to the OsiXpr, then go to 1 (or exit if there are no cuts).

As you see, it does not involve Cbc at all. 

I am very willing to provide you all the information you need. But I do not 
know exactly what you want to know, so please contact me if you have further 
questions. I do not know enough about the source code that I could help you 
there (unless you give me more information). But I can always test newly 
developed code.

Best regards,
  Thomas


Am Sonntag, 4. Juli 2010 21:53:48 schrieb Lou Hafer:
> Thomas, Ted,
>
> 	cbc-generic is an illusion.  This is my attempt to try and maintain
> generic solver capability in cbc.  Unfortunately, it would become broken on
> a regular basis due to changes to the main cbc code base and I have not had
> time over the past year or so to properly maintain it.  I believe that it
> is currently broken (it will compile but will crash during its unit test).
> You have to specifically enable the build with
>   --enable-cbc-generic
> and then choose a solver with
>   --with-cbc-generic-solver=xxxx
> The only solvers cbc-generic has ever been tested with are clp, dylp, and
> glpk. Looking at CbcGenSolvers.cpp, it looks like I might have tested with
> cplex (cpx). Can't think why I coded in Mosek (msk), as I don't have the
> libraries. Code files for cbc-generic start with `CbcGen'.
>
> 	Ted, I don't have the log or other information, but I believe you're
> correct.  The presence/absence of OsiXpr is completely irrelevant to a cbc
> build.  It will use OsiClp (as well as lower-level classes specific to
> clp), and there's nothing you can do about it.  You'll notice that the
> section of Makefile.am that builds the cbc main program is conditional on
> the presence of clp.
>
> 	Thomas, if what you're actually doing is coming in through OsiCbc,
> specifying OsiXpr as the underlying solver, it may or may not work,
> depending on the problem.  And the previous paragraph applies.  Lots of
> activities in libCbc will not work because they're coded specifically for
> clp, at a level at or below the Osi interface.  I'll also add that running
> Cbc through OsiCbc is a lot like doing brain surgery while wearing boxing
> gloves.  You don't have the fine control.
>
> 	Hence our requests for more information.  For myself, it's a case where
> I haven't been able to do serious work on cbc for a while and I didn't want
> to make assertions when the capabilities of the code had possibly changed. 
> But I think it's highly unlikely that you're getting the build you think
> you're getting.
>
> 							Lou
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc