[Clp] Dense LP Problem Interface

Wed Jul 8 20:36:07 EDT 2015

Ipopt crashed as well in libc.so.6. Perhaps it's fundamental to my 
problem?  However is it reasonable that you can feed a problem into one 
of these solvers and have it segfault?
Since I'm not familiar with the foreign function interface for Julia,  
the recompiling process is going to have to wait until I get a few 
chores done.

I wonder if there are incompatible C++ libraries at play?

On 07/08/2015 07:10 PM, Miles Lubin wrote:
> You might try compiling Clp with "--enable-debug --enable-shared" to 
> get a bit more useful info in the backtrace. It could be that Clp is 
> running into the limitations of using 32-bit integers for indexing. It 
> wouldn't be too hard to fix, though I complained 3 years ago about 
> this without much of a response 
> (https://projects.coin-or.org/CoinUtils/ticket/75). From the 
> open-source solvers, Ipopt might be more resilient, though you should 
> compile your own version since the version distributed with Julia uses 
> reference BLAS.
>
> Best,
> Miles
>
> On Wed, Jul 8, 2015 at 4:55 PM, Matt Bromberg <mattcbro at earthlink.net 
> <mailto:mattcbro at earthlink.net>> wrote:
>
>     Yup trying it out now.  I really like Julia so far. There is a lot
>     of innovation there.  Clp doesn't print out intermediate status as
>     it does under Python, or perhaps it just doesn't flush until it's
>     done.
>
>     I like the fact that all the packages are self contained so that,
>     presumably they play well together.  It looks like Clp barfed
>     though.  Segmentation fault as before.
>     So this probably is a limitation of Clp,  which is a shame, since
>     it's memory profile is fantastic.
>
>     I'll have to try other LP solutions to see whats up.
>
>     Thanks for that tip by the way.  I wish I had started with Julia.
>
>     The run time error info:
>     __libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
>     unknown function (ip: 4199667)
>     unknown function (ip: 0)
>     Segmentation fault
>
>
>     -Matt
>
>
>     On 07/08/2015 01:03 PM, Miles Lubin wrote:
>>     Yes, it's very easy to read and write MAT files with the MAT
>>     package (https://github.com/simonster/MAT.jl), also plain HDF5
>>     (https://github.com/timholy/HDF5.jl).
>>
>>     On Wed, Jul 8, 2015 at 10:59 AM, Matt Bromberg
>>     <mattcbro at earthlink.net <mailto:mattcbro at earthlink.net>> wrote:
>>
>>         Thanks for reminding me of this. Looking at the julia
>>         interface was on my todo list.  Is there a julia interface
>>         for matlab files, or hdf5 file formats?
>>         That's one reason I've been using python for scripting.  I
>>         suppose julia can call python too.
>>
>>         I appreciate the code snippet as well.
>>
>>         Matt
>>
>>
>>         On 07/08/2015 12:01 PM, Miles Lubin wrote:
>>>         Hi Matt,
>>>
>>>         You may want to try out the linprog function in Julia:
>>>
>>>         http://mathprogbasejl.readthedocs.org/en/latest/linprog.html
>>>
>>>         All you do is:
>>>
>>>         using MathProgBase
>>>         using Clp
>>>         sol = linprog(c, Acon, '<', rhsvec, -Inf, Inf, ClpSolver())
>>>
>>>         You can also easily switch in commercial solvers.
>>>         Unfortunately I don't know of any well supported solvers
>>>         which are optimized for such large dense problems.
>>>
>>>         Miles
>>>
>>>         On Wed, Jul 8, 2015 at 9:53 AM, Matt Bromberg
>>>         <mattcbro at earthlink.net <mailto:mattcbro at earthlink.net>> wrote:
>>>
>>>             I have yet to see a simple way to use CBC or CLP using
>>>             raw binary data.  In particular I have a large problem
>>>             with 40K constraints 10K variables or so.
>>>             That's about 3Gbytes of raw doubles.  It expands to an
>>>             unwieldy size using any of the text base input formats.
>>>             (hundreds of gigabytes).
>>>
>>>             I can get that data into a python numpy array but it
>>>             does not appear to be easy to dump that raw array into
>>>             CLP. Unfortunately cylp doesn't support the latest API.
>>>             I would roll my own python interface but there is
>>>             literally no documentation I can find online for the C
>>>             interface to something like CoinMP.
>>>
>>>             All the other interfaces appear to be useless for my
>>>             purposes. Pulp is rather arcane and there is no obvious
>>>             way to pull the data back into python.
>>>
>>>             I am in somewhat disbelief that I can't do this:
>>>             [xopt,fmin] = linprog(c, Acon, rhsvec) ;
>>>
>>>             to solve min c' * x  given Acon * x <= rhsvec .
>>>
>>>              The above is the one line matlab interface to linprog.
>>>             There should be something similar in Python in support
>>>             of CLP using it's primary matrix array interface,
>>>             numpy/ndarrays.
>>>             Even my cylp solution takes 10 lines of python code to
>>>             do this, plus half a day of parsing documentation.  It's
>>>             just unfortunate that it segfaults on the larger problems.
>>>
>>>             If anyone has a good way to do this in Python or C, with
>>>             an example I'd love to see it.  For now I have to move
>>>             on to other solvers.
>>>             _______________________________________________
>>>             Clp mailing list
>>>             Clp at list.coin-or.org <mailto:Clp at list.coin-or.org>
>>>             http://list.coin-or.org/mailman/listinfo/clp
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/clp/attachments/20150708/f5dcfdfc/attachment-0001.html>