[Cbc] Cbc Digest, Vol 78, Issue 6

Fri Dec 20 06:17:16 EST 2013

John,

Thank you very much for quick and efficient reply!
I have just a couple of questions.

First, do you know when this fix will be released?

Then, i am wondering if doing a constant propagation could help the solver.
My constraints file is generated by a piece of code which do not try to 
optimize them.
For instance, the following sequence:
_C0: var_0 = 0
_C1: var_0 + var_2 >= var_3

could be replaced with:
_c0: var_2 >= var_3

Yves

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Dec 2013 19:48:38 +0000
> From: John Forrest <john.forrest at fastercoin.com>
> To: cbc at list.coin-or.org
> Subject: Re: [Cbc] Constraints order
> Message-ID: <52B1FC16.6030301 at fastercoin.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Yves,
>
> Error not where I thought it was.  Small changes i.e. order or compiler
> or anything made a subtle difference and a constraint was generated
>
> x995 + x1018 + x1700 >= 1.0000001001
>
> and the optimal solution had x995==0,x1018==1 and x1700==0 - but it was
> within tolerances (just)
>
> One of the cut generators then thought 0.0000001001 is greater than
> primal tolerance of 1.0e-7 and created a bad cut.
>
> I have modified code to be a bit more relaxed.
>
> John Forrest
>
> On 18/12/13 10:11, Yves Touchard wrote:
>> Attached is a archive file (test.gz) containing an lp constraint file
>> (test.lp -> /tar xzf test.gz/)
>>
>> Executing cbc (#2.8.0)  on the test.lp file (/cbc test.lp/) provides
>> the following result
>> /Result - Problem proven infeasible//
>> //No feasible solution found
>>
>> /If the two first constraints of the LP file (lines 1258/1259) are
>> swapped, the same command provides a different result:
>> /Result - Optimal solution found/
>>
>> So, what's wrong with this constraints fle? Is there any specific
>> order to declare constraints?
>> Or is this a bug? And, if so, is there any workaround?
>>
>> Thanks in advance for any help.
>>
>> Regards,
>>
>> Yves
>>
>>
>>
>>
>> _______________________________________________
>> Cbc mailing list
>> Cbc at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/cbc
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://list.coin-or.org/pipermail/cbc/attachments/20131218/5c50a313/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Dec 2013 16:44:40 +0100
> From: Cornelius Riemenschneider <cri at itscope.de>
> To: John Forrest <john.forrest at fastercoin.com>,
> 	"=?windows-1252?Q?cbc=40list.coin-or.org?=" <cbc at list.coin-or.org>
> Subject: Re: [Cbc] Threadsafe usage of Cbc
> Message-ID: <zarafa.52b31468.16aa.50cb38f25c72147c at noriswww>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
>
> thank you very much for your work!
>
> As I?ll be away for the holidays, I?ll try your patch in the new year and will report back.
>
> Can you elaborate on the cut generator problem? Is it user-specified which one is used, or is this a choice done by the algorithm?
>
> And can you point me at the source code for them, so that I can check them for thread safety in case we actually use them?
>
> ?
>
> Regards,
>
> Cornelius Riemenschneider
>
> --
>
> ITscope GmbH
>
> Ludwig-Erhard-Allee 20
>
> 76131 Karlsruhe
>
> Email: cornelius.riemenschneider at itscope.de
>
> https://www.itscope.com
>
> Handelsregister: AG Mannheim, HRB 232782
>
> Sitz der Gesellschaft: Karlsruhe
>
> Gesch?ftsf?hrer: Alexander M?nkel, Benjamin Mund, Stefan Reger
>
>
> ?
>
> Von: john.forrest at fastercoin.com [mailto:cbc-bounces at list.coin-or.org] Im Auftrag von John Forrest
> Gesendet: Mittwoch, 18. Dezember 2013 14:23
> An: cbc at list.coin-or.org
> Betreff: Re: [Cbc] Threadsafe usage of Cbc
>
>
>
> ?
>
> Cornelius,
>
> I have made some changes, which I hope will be enough for you.? I have done the minimum amount of work.
>
> I don't think they can hurt anyone but as Ted Ralphs is preparing a new release, I will delay updating Cbc/stable/CbcSolver.?pp for a day or two.? If anyone wants to test the code I attach CbcSolver.?pp.
>
> You need to compile with -DCBC_THREAD_SAFE.? The main thing this does is that Cbc only reads argv/argc type parameters in a crude threadsafe way.? You also need to use alternative versions of CbcMain0/1.
>
> parallel.cpp has been added to Cbc/examples which is a simple example.
>
> Please tell me if there are any problems.? Some lesser used Cgl cut generators may not be threadsafe, but I think the commonly used ones are.
>
> John Forrest
>
>
> On 17/12/13 15:11, Cornelius Riemenschneider wrote:
>
>
> Hello,
>
> we use CBC via googles or-tools from java in our application.
>
> Compared to scientific problems, our problems are small and solved by Cbc in <1s (which is great!).
>
> As we process requests from users concurrently, we?d also like to call Cbc concurrently.
>
> Currently, this is impossible, because Cbc uses the static parameters array in CbcMain0 and CbcMain1 and thus crashes or reads incorrect parameters.
>
> One backtrace, for example is:
>
> ?
>
> #2 0x00007fb3435bf52b in __libc_message (do_abort=<optimized out>, fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> #3 0x00007fb3435c8d76 in malloc_printerr (action=3, str=0x7fb3436a1248 "double free or corruption (!prev)", ptr=<optimized out>) at malloc.c:6283
> #4 0x00007fb3435cdaac in *__GI___libc_free (mem=<optimized out>) at malloc.c:3738
> #5 0x00007fb342733f06 in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #6 0x00007fb2d652cb7b in establishParams(int&, CbcOrClpParam*) () from libjnilinearsolver.so
> #7 0x00007fb2d64edc3b in CbcMain0(CbcModel&) () from libjnilinearsolver.so
> #8 0x00007fb2d6511bec in callCbc(char const*, CbcModel&) () from libjnilinearsolver.so
> #9 0x00007fb2d64e3fce in operations_research::CBCInterface::Solve(operations_research::MPSolverParameters const&) () from libjnilinearsolver.so
> #10 0x00007fb2d64cfe45 in operations_research::MPSolver::Solve(operations_research::MPSolverParameters const&) () from libjnilinearsolver.so
> #11 0x00007fb2d64cff3b in operations_research::MPSolver::Solve() () from libjnilinearsolver.so
> #12 0x00007fb2d64c91cf in Java_com_google_ortools_linearsolver_mainJNI_MPSolver_1solve_1_1SWIG_10 () from libjnilinearsolver.so
>
> # from here on it?s just the JVM
>
> ?
>
> As I don?t know the code and it?s hard to read, I can?t really fix the problem by myself,
>
> but wouldn?t it be better to move parameters inside CbcModel instead of having a static array laying around?
>
> ?
>
> Andi f that?s done (or another solution is found), do you know of any thread-safety issues in cbc?
>
> Keep in mind, we don?t want Cbc to solve our problem in multiple threads, we just want to be able to solve different problems simultaneous.
>
> ?
>
> Regards,
>
> Cornelius Riemenschneider
>
> --
>
> ITscope GmbH
>
> Ludwig-Erhard-Allee 20
>
> 76131 Karlsruhe
>
> Email: cornelius.riemenschneider at itscope.de
>
> https://www.itscope.com
>
> Handelsregister: AG Mannheim, HRB 232782
>
> Sitz der Gesellschaft: Karlsruhe
>
> Gesch?ftsf?hrer: Alexander M?nkel, Benjamin Mund, Stefan Reger
>
> ?
>
>
>
>
>
>
>
> _______________________________________________
>
> Cbc mailing list
>
> Cbc at list.coin-or.org
>
> http://list.coin-or.org/mailman/listinfo/cbc
>
> ?
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://list.coin-or.org/pipermail/cbc/attachments/20131219/e823dada/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc
>
>
> End of Cbc Digest, Vol 78, Issue 6
> **********************************