Opened 4 years ago

Closed 3 weeks ago

#161 closed defect (migrated)

Wrong optimum with files from MIPLIB2010

Reported by: charlesBrixko Owned by: tkr
Priority: major Component: Cbc
Version: 2.7 Keywords: optimum MIPLIB2010
Cc:

Description

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".

Change History (6)

comment:1 Changed 4 years ago by tkr

  • Status changed from new to assigned
  • Version set to 2.7

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?

comment:2 Changed 4 years ago by charlesBrixko

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 r2135 et stable/2.9 révision r2136
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

comment:3 Changed 4 years ago by tkr

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.

Last edited 4 years ago by tkr (previous) (diff)

comment:4 Changed 4 years ago by charlesBrixko

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".

comment:5 Changed 4 years ago by charlesBrixko

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.

comment:6 Changed 3 weeks ago by stefan

  • Resolution set to migrated
  • Status changed from assigned to closed

This ticket has been migrated to GitHub and will be resolved there: https://github.com/coin-or/Cbc/issues/161

Note: See TracTickets for help on using tickets.