Wrong optimum with files from MIPLIB2010

[svigerske]

Issue created by migration from Trac.

Original creator: charlesBrixko

Original creation time: 2015-02-17 08:59:16

Assignee: @tkralphs

Version:

Keywords: optimum MIPLIB2010

I use cbc (2.9.2) compiled with internal BLAS and internal LAPACK and with the parallel option enabled.

With files from MIPLIB2010 and using 4 or 8 threads, I get the following wrong results :

• lectsched-1.mps, lectsched-2.mps, lectsched-3.mps and lectsched-4-obj.mps gives each "infeasible".
• mik-250-1-100-1.mps gives the right optimum 50% of the time, giving a wrong optimum the other times.
• ofi gives the wrong optimum "12768339254.94019508".

[svigerske]

Comment by @tkralphs created at 2015-02-20 04:47:33

A bug that arose with lectsched-1.mps was fixed recently in stable/2.9 and will be in the next release. Can you see if that fixes the problem?

[svigerske]

Comment by @tkralphs created at 2015-02-20 04:47:33

Changing status from new to assigned.

[svigerske]

Comment by @tkralphs created at 2015-02-20 04:47:33

Version: 2.7

[svigerske]

Comment by charlesBrixko created at 2015-02-21 02:14:26

I used version 2.9.2 and I was unable to set the correct Version number on the ticket because it didn't allow me to do so.

The result of :

Modifications entre releases/2.9.2 révision 5962995 et stable/2.9 révision f6f52f9

concerns only minor informations (ex.: version number) and probably won't change the behavior.

Did you mean "trunk" ? which is not coming from version 2.9.2

I'm using FEDORA 21 with gcc 4.9.2

[svigerske]

Comment by @tkralphs created at 2015-02-22 00:07:15

Sorry for the lack of ability to set the version. I have fixed that now. I did realize that you were using 2.9.2. The recent bug fix was not in Cbc itself, but in one of the dependent projects (Cgl), so updating should fix the problem, as long as you also update the externals, too (which happens automatically if you check out with subversion). I actually did not mean the trunk version, I meant the stable/2.9 branch in svn, which is the branch from which we make releases for the 2.9 series. What is there (along with the externals) will be the next release once we test it. You can get it with SVN by doing

svn co https://projects.coin-or.org/svn/Cbc/stable/2.9

You can also just wait for release 2.9.3 and it will hopefully be fixed there. Hopefully, that all makes sense.

[svigerske]

Comment by charlesBrixko created at 2015-02-23 05:49:31

The following results are for the stable/2.9 branch in svn before the release 2.9.3, with all or without any of the Third Party software, with 4 or 8 threads :

• lectsched-2.mps is found correctly with great difference in time to find the solution (depending on the test, from 716 to 664862 Enumerated nodes).

• the others lectsched-x.mps should be found too, it takes too long to be checked for this post.

• mik-250-1-100-1.mps and ofi.mps still give wrong results the same way.

• for ofi.mps, we always see in the output "Feasibility pump exiting with objective of 1.27683e+10".

[svigerske]

Comment by charlesBrixko created at 2015-03-21 01:23:06

I use cbc parallel 2.9.3 stable (20 march 2015) with 8 threads and "-constraint conflict" and without any Third Party software.

The three files lectsched-2.mps, mik-250-1-100-1.mps and ofi.mps give good results. I didn't see the end of the treatment of ofi.mps but now the bounds stay correct.

I finished my test session with three repeatable behaviours :

• harp2.mps give wrong optimum (all 5 tests)
• neos-1396125.mps give "segmentation fault" (all 10 tests, most in less than 10 minutes)
• transportmoment.mps gives wrong infeasible (all 8 tests, in less than a second)

I hope this will help.

[svigerske]

@h-g-s has been doing some runs of Cbc on MIPLib 2010, I believe, and may have an idea how this looks with current Cbc.

[h-g-s]

I'll check it. There were some non thread safe routines in CBC, maybe this is related.