[Coin-lpsolver] (no subject) (should be: possible slow solving with CLP)

[Kish Shen]

John,

Thanks again for your reply!

Sorry - I forgot to include a subject in my original posting, as I copied
the message from a bounced mail (my original post was done in a hurry and I
mistyped the mailing list address), and forgot to put in the subject...

>What driver are you using and what compiler?

I have tried two ways to solve the l30 problem with Clp's dual Simplex:

1)

Originally I was using the OsiCbc interface, with a call to initialSolve()
to solve a linear problem like l30 (and no integer columns). 

I simply compiled all the COIN components with the default settings, except
specifying -O and without -g for compilation.

I use gcc 2.3.4 linking with glibc 2.0 on Linux. The timings are done on
2GHz Pentium 4 Linux boxes [I compile and run on different machines --
as these 2GHz machines we have has a older gcc that has problems compiling
the COIN components, but we have a dozen of them and they are faster]

One possible difference is that I don't solve the MPS file directly, so
the order of the rows/columns may be different from when the problem is
solved from the MPS file. 

2)
I then tried solving the problem using Clp's testit program, using the
`driver' driver, again compiled with the same gcc 2.3.4 configuration.

Here, with the dual solver, and solving l30 from the MPS file, Clp seems to 
get into an obvious loop, here is where it seems to start:

Clp0006I 7388  Obj -176.227 Primal inf 1.43572e+06 (419)
Clp0006I 7389  Obj -25.5449 Primal inf 1.23023e+06 (416)
Clp0006I 7390  Obj -30.2813 Primal inf 570032 (413)
Clp0006I 7391  Obj 120.83 Primal inf 659060 (409)
Clp0006I 7392  Obj 14.7871 Primal inf 543469 (415)
Clp0006I 7393  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7395  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7396  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7398  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7399  Obj 43.6816 Primal inf 1.50536e+06 (414)
Clp0006I 7400  Obj 14.7871 Primal inf 543469 (415)
Clp0006I 7401  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7403  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7404  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7406  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7407  Obj 43.6816 Primal inf 1.50536e+06 (414)
Clp0006I 7408  Obj 14.7871 Primal inf 543469 (415)
Clp0006I 7409  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7411  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7412  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7414  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7415  Obj 43.6816 Primal inf 1.50536e+06 (414)
Clp0006I 7416  Obj 14.7871 Primal inf 543469 (415)
Clp0006I 7417  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7419  Obj 23.1582 Primal inf 817259 (418)
Clp0006I 7420  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7422  Obj 43.9863 Primal inf 247895 (421)
Clp0006I 7423  Obj 43.6816 Primal inf 1.50536e+06 (414)
Clp0006I 7424  Obj 14.7871 Primal inf 543469 (415)
Clp0006I 7425  Obj 23.1582 Primal inf 817259 (418)

but there is no obvious loop for the original run (case 1, above, which I
left running for 2 days). For this case, I can generate the calls I
made to the OSI interface, which can then be compiled separately and
will hopefully reporduce the problem without using our ECLiPSe system
(which is how I have bveen using OSI). Do you want me to do this and send
the program to you?

Cheers,

Kish