[Cbc] Cbc Digest, Vol 78, Issue 7

Mon Jan 6 05:20:10 EST 2014

John,

I've not realized that this mail was including my answer. And, i did not 
see yours...
Thanks for your fix.
That works fine!

Regards,

Yves

On 12/20/2013 06:00 PM, cbc-request at list.coin-or.org wrote:
> Send Cbc mailing list submissions to
> 	cbc at list.coin-or.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://list.coin-or.org/mailman/listinfo/cbc
> or, via email, send a message with subject or body 'help' to
> 	cbc-request at list.coin-or.org
>
> You can reach the person managing the list at
> 	cbc-owner at list.coin-or.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cbc digest..."
>
>
> Today's Topics:
>
>     1. Re: Threadsafe usage of Cbc (Pietro Belotti)
>     2. Re: Cbc Digest, Vol 78, Issue 6 (Yves Touchard)
>     3. Re: Constraints order (John Forrest)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Dec 2013 18:59:12 +0000
> From: Pietro Belotti <petr.7b6 at gmail.com>
> To: Cornelius Riemenschneider <cri at itscope.de>
> Cc: "cbc at list.coin-or.org" <cbc at list.coin-or.org>
> Subject: Re: [Cbc] Threadsafe usage of Cbc
> Message-ID:
> 	<CAA1=4dgC3d8XKuxRTLLOTcGEOOa3dE21ZW_PkVUU0rPLoUtnMQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> A bit more information about Couenne: there is some code in Couenne to
> make it possible, in the future, to use threads (for instance, it can
> be configured with --enable-cbc-parallel), but as far as I understand
> Couenne is still sequential. There are a few major changes to be made
> for this to happen. I was able to code a Branch-and-bound for problems
> with a specific class of nonlinear constraints and it does run in
> parallel (under Linux only), but that's that.
>
> Pietro
>
> On Thu, Dec 19, 2013 at 3:44 PM, Cornelius Riemenschneider
> <cri at itscope.de> wrote:
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Cbc mailing list
>> Cbc at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/cbc
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Dec 2013 12:17:16 +0100
> From: Yves Touchard <ytouchard at dxo.com>
> To: <cbc at list.coin-or.org>
> Subject: Re: [Cbc] Cbc Digest, Vol 78, Issue 6
> Message-ID: <52B4273C.7020805 at dxo.com>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> 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
>> **********************************
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Dec 2013 14:19:00 +0000
> From: John Forrest <john.forrest at fastercoin.com>
> To: cbc at list.coin-or.org
> Subject: Re: [Cbc] Constraints order
> Message-ID: <52B451D4.1040102 at fastercoin.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Yves,
>
> Fix is in Cgl/stable/0.58 so if you are using svn just update.  I don't
> know when next release will be.  As it only one file that has been
> changed you could also just download it from
>
> https://projects.coin-or.org/Cgl/browser/stable/0.58/Cgl/src/CglProbing/CglProbing.cpp
>
> The change you suggest would improve solution times by a tiny tiny
> amount - but it normally is best to keep your code as simple (and
> therefore bug free) as possible.
>
> John Forrest
>
> On 20/12/13 11:17, Yves Touchard wrote:
>> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://list.coin-or.org/pipermail/cbc/attachments/20131220/85139982/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 7
> **********************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20140106/b8823d5c/attachment-0001.html>