[Coin-discuss] Using CBC with OSI

[John J Forrest]

Kish,

After the dynamic cast there should have been a test if (osiclp&&...)

OsiCbc was just a mistake on my part when I indulged someones' whim.

If you send me log files I can give some suggestions.  It may be to do 
with CbcStrategy where you are getting a default strategy which may 
override something.

John Forrest



Kish Shen <ks15 at icparc.ic.ac.uk> 
Sent by: coin-discuss-bounces at list.coin-or.org
08/17/2005 01:51 PM
Please respond to
Discussions about open source software for Operations Research 


To
coin-discuss at list.coin-or.org
cc

Subject
[Coin-discuss] Using CBC with OSI






Hi,

I have been trying out Osi as an interface to different MP solvers. One of
these is Cbc, compiled with Clp as the linear solver. 

To allow for different solvers with the same code, I use the
OsiXxxSolverInterface declaration as suggested in the tutorial
documentations:

#ifdef COIN_USE_CBC
#include "OsiCbcSolverInterface.hpp"
typedef OsiCbcSolverInterface OsiXxxSolverInterface;
#endif

To solve a MIP problem, I originally had:

lpd->lp->initialSolve());
lpd->lp->branchAndBound());

where lpd->lp is a * OsiXxxSolverInterface.

I also tried running the various drivers for the `testit' test program in
Cbc's sample directory, and I noticed that the driver sample2 seem to 
perform
significantly better than the results I am getting with the above simple
call to branchAndBound() for the more difficult problems I tested. 

I ran into some problems when I tried to adapt the sample2 code for my own
program, and I am hoping that I can get some help with this. Thanks in
advance for any help/information on this!


In my program, I tried to use as much of the sample2.cpp code as possible,
with only the initial code to get the solver being different:


    OsiSolverInterface * mipsolver = lpd->lp;
    CglPreProcess process;

    mipsolver = process.preProcess(*(lpd->lp), false, 5);
    mipsolver->resolve();

    CbcModel model(*mipsolver);

instead of

  solver1.initialSolve();
  // Reduce printout
  solver1.setHintParam(OsiDoReducePrint,true,OsiHintTry);
  // See if we want preprocessing
  OsiSolverInterface * solver2=&solver1;
  CglPreProcess process;
  if (preProcess) {
    /* Do not try and produce equality cliques and
       do up to 5 passes */
    solver2 = process.preProcess(solver1,false,5);
    if (!solver2) {
      printf("Pre-processing says infeasible\n");
      exit(2);
    }
    solver2->resolve();
  }
  CbcModel model(*solver2);

====
The rest of the code, until the call to branchAndBound(), was just copied
from sample2.cpp.

1) is the first call to initialSolve() usefull/necessary? The 
preprocessing
seems to solve the problem also.

2) I didn't check if the problem was infeasible after preprocessing, as I
   don't expect the test cases I was using to be infeasible.

When I tried running this code, the program seg faults when running

  OsiClpSolverInterface * osiclp = dynamic_cast< OsiClpSolverInterface*> 
(model.solver());

  // go faster stripes
  if (osiclp->getNumRows()<300&&osiclp->getNumCols()<500) {
    //osiclp->setupForRepeatedUse(2,0);

    osiclp->setupForRepeatedUse(0,0);
  } 


It seems to happen when calling getNumRows(). I assume the problem is
related to casting the model.solver() to an OsiClpSolverInterface *, when
what I have is OsiCbcSolverInterface *. Is there anyway I can do this
casting correctly?

I commented out this code and was able to compile and run the
code. However, the timings I get is much worse than running testit with
sample2, across a range of programs. For example, for the MIPLIB problem
air04, I aborted the execution of my program when it had already spent 
more
than 100 times longer than the time to solve the problem with
testit/sample2. I was very surprised by this, as I had expected similar
timngs (except maybe when the problem is small and the above call to
setupForRepeatedUse() was made).

I suspected that because in my code, I actually create and fill in the
problem matrix rather than reading the problem in as an MPS file, then the
column/row orders might be different, and this might lead to the
differences, but I would not expect this would make my timings to be
more or less consistently worse than those of testit/sample2. 

To try to get round this possible rearrangement of the columns and rows, I 

wrote out a MPS file of the problem in my program, and ran testit on this
MPS file. Am I correct in thinking that the row/column orders are 
preserved
by the MPS format? In any case, I still get the same timing differences.

Any ideas on why there is such a big difference in the solving times? Am I
missing something?

Again, thanks in advance for any help/information!

Cheers,

Kish Shen
IC-Parc
Imperial College London
U.K.
_______________________________________________
Coin-discuss mailing list
Coin-discuss at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/coin-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20050818/6eeb6829/attachment.html>