Git Product home page Git Product logo

cbc.old's Introduction

CBC Version 2.10.0 README

Welcome to the README for the COIN Branch and Cut Solver (CBC). CBC is distributed under the Eclipse Public License and is freely redistributable. All source code and documentation is Copyright IBM and others. This README may be redistributed freely.

CURRENT BUILD STATUS

Build Status

Build status

DOWNLOAD

Download

Binaries for most platforms are available for download from Bintray

CITE

DOI

DOCUMENTATION

For a quick start guide, please see the INSTALL file in this distribution. A (somehwat outdated) user's manual is available here:

http://www.coin-or.org/Cbc

More up-to-date automatically generated documentation of the source code can be found here:

http://www.coin-or.org/Doxygen/Cbc/

Further information can be found here:

http://projects.coin-or.org/Cbc

SUPPORT

List Serve

CBC users should use the Cbc mailing list. To subscribe, go to http://list.coin-or.org/mailman/listinfo/cbc

Bug Reports

Bug reports should be reported on the CBC development web site at

https://projects.coin-or.org/Cbc/newticket

CHANGELOG

  • Release 2.10.0

    • Improved handling of SOS, starting point, and symmetries
    • Improved performance of primal heuristics regarding the handling of implicit integer variables
    • Mini-B&B is now disabled when solving with multiple threads
    • Changed default value for zero half cuts parameter from off to ifmove
    • Added CbcModel::postProcessedSolver() to obtained LP after presolve
    • New option "PrepNames" to indicate whether column names should be kept in the pre-processed model
    • New option "sosPrioritize" to determine how to prioritize SOS
    • Added new event "generatedCuts"
    • CbcSolver can now read compressed .lp files (GZIP, BZIP2)
    • New functions in the C interface: Cbc_readLp, Cbc_writeLp, Cbc_addCol, Cbc_addRow, Cbc_getNumIntegers, Cbc_bestSolution, Cbc_getObjValue, Cbc_getRowNz, Cbc_getRowIndices, Cbc_getRowCoeffs, Cbc_getRowRHS, Cbc_getRowSense, Cbc_getColNz, Cbc_getColIndices, Cbc_getColCoeffs, Cbc_getReducedCost, Cbc_numberSavedSolutions, Cbc_savedSolution, Cbc_savedSolutionObj, Cbc_setMIPStart, Cbc_setMIPStartI, Cbc_addCutCallback, Osi_getNumCols, Osi_getColName, Osi_getColLower, Osi_getColUpper, Osi_isInteger, Osi_getNumRows, Osi_getRowNz, Osi_getRowIndices, Osi_getRowCoeffs, Osi_getRowRHS, Osi_getRowSense, Osi_getColSolution, OsiCuts_addRowCut, Cbc_getAllowableGap, Cbc_setAllowableGap, Cbc_getAllowableFractionGap, Cbc_setAllowableFractionGap, Cbc_getAllowablePercentageGap, Cbc_setAllowablePercentageGap, Cbc_getCutoff, Cbc_setCutoff, Cbc_getMaximumNodes, Cbc_setMaximumNodes, Cbc_getMaximumSolutions, Cbc_setMaximumSolutions, Cbc_getLogLevel, Cbc_setLogLevel, Cbc_getMaximumSeconds, Cbc_setMaximumSeconds
    • New action "guess" checks properties of the model to decide the best parameters for solving the LP relaxation.
    • New example inc.cpp to illustrate solution callback
    • New example driver5.cpp to illustrate user-defined branching rule
    • New example clpdriver.cpp to illustrate use of ClpEventHandler
    • Added support for using OsiHiGHS with CbcGeneric
    • Added MSVC 14 project files
    • Bugfixes
  • Release 2.9.10

    • Fix a numerical issue
    • Fix some memory leaks
    • Fix issue when root node is obviously infeasible
    • Performance improvements for mini-B&B
    • Fix name of bound in final message
    • Fix names in preprocessed problem
  • Release 2.9.9

    • Fixes for SOS2
    • Updates to mipstart
    • Switching to new build system
    • Updates for CI
  • Release 2.9.8

    • Update to most current releases of dependencies
    • Small bug fixes
    • Add support for automatic build and test with Travis and Appveyor
  • Release 2.9.7

    • Small bug fixes
    • Option to switch to line buffered output
  • Release 2.9.6

    • Small bug fixes
  • Release 2.9.5

    • Small bug fixes
  • Release 2.9.4

    • Small fixes for stability
    • Fixes for Doygen documentation generation
  • Release 2.9.3

    • Minor bug fixes
  • Release 2.9.2

    • Fix for proper installation with DESTDIR
  • Release 2.9.1

    • Fix for dependency linking
    • Minor bug fixes
  • Release 2.9.0

    • Introduced specialized branching methods for dealing with "big Ms".
    • Introduced new methods for dealing with symmetry (requires installation of nauty)
    • Introduction of conflict cuts (off by default, turn on with -constraint conflict)
  • Release 2.8.13

    • Improved message handling
    • Miscellaneous bug fixes.
  • Release 2.8.12

    • Update for dependencies.
  • Release 2.8.11

    • Major overhaul of C interface
    • Fixes to SOS
    • Miscellaneous bug fixes
  • Release 2.8.10

    • More changes related to thread safety.
    • Fix bug in build system with Visual Studio compiler.
    • Miscellaneous bug fixes.
  • Release 2.8.9

    • Attempt to make Cbc thread safe.
    • Add parallel examples.
    • Add CbcSolverUsefulInfo.
    • Bug fixes.
  • Release 2.8.8

    • Added example to show how to use Cbc with installed libraries in MSVC++
    • Fixed inconsistency in addition of libCbcSolver to dependencies in {{{cbc_addlibs.txt}}}.
  • Release 2.8.7

    • Changed so that Doxygen builds LaTex
    • Fixes for build system
  • Release 2.8.6

    • Added option to explicitly link dependencies to comply with packaging requirements on Fedora and Debian, as well as allow building of MinGW DLLs.
  • Release 2.8.5

    • Minor fixes to build system
  • Release 2.8.4

    • Small bug fixes
    • Upgrades to build system
  • Release 2.8.3:

    • Fix for handling SOS.
  • Release 2.8.2:

    • Fixed recognition of Glpk source in main configure.
    • Minor bug fixes in CoinUtils, Clp, and Cbc.
  • Release 2.8.1:

    • Minor bug fixes
  • Release 2.8.0:

    • Introduced new secondaryStatus 8 to indicate that solving stopped due to an iteration limit.

    • Solution pool is now accessible via the command line and the CbcMain* interface.

    • New mipstart option to read an initial feasible solution from a file. Only values for discrete variables need to be provided.

    • Added Proximity Search heuristic by Fischetti and Monaci (off by default): The simplest way to switch it on using stand-alone version is -proximity on.

      Proximity Search is the new "No-Neighborhood Search" 0-1 MIP refinement heuristic recently proposed by Fischetti and Monaci (2012). The idea is to define a sub-MIP without additional constraints but with a modified objective function intended to attract the search in the proximity of the incumbent. The approach works well for 0-1 MIPs whose solution landscape is not too irregular (meaning the there is reasonable probability of finding an improved solution by flipping a small number of binary variables), in particular when it is applied to the first heuristic solutions found at the root node.

    • An implementation of Zero-Half-Cuts by Alberto Caprara is now available. By default, these cuts are off. To use add to your command line -zerohalfCuts root (or other options) or just -zero. So far, they may help only on a small subset of problems and may need some tuning.

      The implementation of these cuts is described in G. Andreello, A. Caprara, and M. Fischetti "Embedding Cuts in a Branch and Cut Framework: a Computational Study with {0,1/2}-Cuts" INFORMS Journal on Computing 19(2), 229-238, 2007 http://dx.doi.org/10.1287/ijoc.1050.0162

    • An alternative implementation of a reduce and split cut generator by Giacomo Nannicini is now available. By default, these cuts are off. To use add to your command line -reduce2AndSplitCuts root (or other options).

      The implementation of these cuts is described in G. Cornuejols and G. Nannicini "Practical strategies for generating rank-1 split cuts in mixed-integer linear programming" Mathematical Programming Computation 3(4), 281-318, 2011 http://dx.doi.org/10.1007/s12532-011-0028-6

    • An alternative robust implementation of a Gomory cut generator by Giacomo Nannicini is now available. By default, these cuts are off. To use add to your command line -GMI root (or other options).

      The implementation of these cuts is described in G. Cornuejols, F. Margot, and G. Nannicini "On the safety of Gomory cut generators" http://faculty.sutd.edu.sg/~nannicini/index.php?page=publications

    • To encourage the use of some of the more exotic/expensive cut generators a parameter -slowcutpasses has been added. The idea is that the code does these cuts just a few times - less than the more usual cuts. The default is 10. The cut generators identified by "may be slow" at present are just Lift and project and ReduceAndSplit (both versions).

    • Allow initialization of random seed by user. Pseudo-random numbers are used in Cbc and Clp. In Clp they are used to break ties in degenerate problems, while in Cbc heuristics such as the Feasibility Pump use them to decide whether to round up or down. So if a different pseudo-random seed is given to Clp then you may get a different continuous optimum and so different cuts and heuristic solutions. This can be switched on by setting randomSeed for Clp and/or randomCbcSeed for Cbc. The special value of 0 tells code to use time of day for initial seed.

    • Building on this idea, Andrea Lodi, Matteo Fischetti, Michele Monaci, Domenico Salvagnin, Yuji Shinano, and Andrea Tramontani suggest that this idea be improved by running at the root node with multiple copies of solver, each with its own different seed and then passing in the solutions and cuts so that the main solver has a richer set of solutions and possibly stronger cuts. This is switched on by setting -multipleRootPasses. These can also be done in parallel.

    • Few changes to presolve for special variables and badly scaled problems (in CoinUtils).

    • New option -extraVariables which switches on a trivial re-formulation that introduces extra integer variables to group together variables with same cost.

    • For some problems, cut generators and general branching work better if the problem would be infeasible if the cost is too high. If the new option -constraintFromCutoff is set, the objective function is added as a constraint which rhs is set to the current cutoff value (objective value of best known solution).

  • Release 2.7.8:

    • Change message when LP simplex iteration limit is hit from "Exiting on maximum nodes" to "Exiting on maximum number of iterations"
    • Fix for using overlapping SOS.
    • Fixes in buildsystem.
  • Release 2.7.7:

    • Fix to report interruption on user event if SIGINT is received by CbcSolver. model->status() should now be 5 if this event happened. Added method CbcModel::sayEventHappened() to make cbc stop due to an 'user event'.

    • Other minor fixes.

  • Release 2.7.6:

    • Fixes to build system.

    • Other minor fixes.

  • Release 2.7.5:

    • Fixes to get AMPL interface working again.

    • More fixes to MSVC++ files.

  • Release 2.7.4:

    • Minor bugfixes.
  • Release 2.7.3:

    • Minor bugfixes.

    • Fixes to MSVC++ files.

  • Release 2.7.2:

    • Allow row/column names for GMPL models.

    • Added CbcModel::haveMultiThreadSupport() to indicate whether Cbc library has been compiled with multithread support.

    • Added CbcModel::waitingForMiniBranchAndBound() to indicate whether sub-MIP heuristic is currently running.

    • Cbc shell should work with readline if configured with --enable-gnu-packages.

    • Support for compressed input files (.gz, .bz2) is now enabled by default.

    • Fix problems with relative gap tolerance > 100% and further bugs.

    • Fixes for MSVC++ Version 9 files.

    • Minor fixes in buildsystem; update to BuildTools 0.7.1.

  • Release 2.7.1:

    • Fixes to MSVC++ files
  • Release 2.7.0:

    • License has been changed to the EPL.

    • Support for MSVC++ version 10 added.

    • Support for BuildTools version 0.7 to incorporate recent enhancements, including proper library versioning in Linux, prohibiting installation of private headers, etc.

    • Updated externals to new stable versions of dependent projects.

    • Improvements to heuristics.

    • New options for cut generation.

    • Improved reporting of results.

    • Improvements to documentation.

    • Minor bug fixes.

cbc.old's People

Contributors

bjarnimax avatar edwinstraver avatar h-g-s avatar h-i-gassmann avatar johnjforrest avatar jpfasano avatar jpgoncal1 avatar louhafer avatar mjsaltzman avatar mlubin avatar rlougee avatar svigerske avatar tkralphs avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cbc.old's Issues

[Trac #140] Crash after 2 hours

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-140.zip

Compiled on MacMini with MacOS10.9.

Cbc0010I After 57200 nodes, 11078 on tree, 1503585.8 best solution, best possible 1363534.2 (7831.46 seconds) libc++abi.dylib: terminating with uncaught exception of type CoinError Abort trap: 6

Crash also occurs in 2.8.7:

Cbc0010I After 2720800 nodes, 12916 on tree, 1493461.3 best solution, best possible 1363534.2 (132717.53 seconds) libc++abi.dylib: terminating with uncaught exception of type CoinError Abort trap: 6

[Trac #182] heap-buffer-overflow in CoinMpsCardReader

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-182.zip

Hello.

I found a heap-buffer-overflow in cbc.

Please confirm.

Thanks.

Summary: heap-buffer-overflow

OS: CentOS 7 64bit

Version: Trunk (unstable)

Steps to reproduce:

1.Download the .POC files.

2.Compile the source code with ASan.

3.Execute the following command : ./cbc $POC

ASAN:DEADLYSIGNAL
=================================================================
==27178==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x607000001c00 at pc 0x0000016b9ee8 bp 0x7ffdf1820480 sp 0x7ffdf1820478
READ of size 8 at 0x607000001c00 thread T0
    #0 0x16b9ee7 in CoinMpsCardReader::~CoinMpsCardReader() /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:471:3
    #1 0x16b9ee7 in CoinMpsIO::gutsOfDestructor() /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:5473
    #2 0x16d3aa8 in CoinMpsIO::~CoinMpsIO() /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:5441:3
    #3 0xc2c8ee in OsiClpSolverInterface::readMps(char const*, bool, bool) /home/karas/Cbc/Clp/src/OsiClp/OsiClpSolverInterface.cpp:5846:1
    #4 0x561814 in CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) /home/karas/Cbc/Cbc/src/CbcSolver.cpp:7955:53
    #5 0x5254b6 in main /home/karas/Cbc/Cbc/src/CoinSolve.cpp:350:22
    #6 0x7f29364a51c0 in __libc_start_main /build/glibc-CxtIbX/glibc-2.26/csu/../csu/libc-start.c:308
    #7 0x42e049 in _start (/home/karas/Cbc/run/bin/cbc+0x42e049)

0x607000001c00 is located 14 bytes to the right of 66-byte region [0x607000001bb0,0x607000001bf2)
freed by thread T0 here:
    #0 0x521ba0 in operator delete(void*) (/home/karas/Cbc/run/bin/cbc+0x521ba0)
    #1 0x15af88e in __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/ext/new_allocator.h:125:2
    #2 0x15af88e in __gnu_cxx::__alloc_traits<std::allocator<char> >::deallocate(std::allocator<char>&, char*, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/ext/alloc_traits.h:133
    #3 0x15af88e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.h:226
    #4 0x15af88e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.h:221
    #5 0x15af88e in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.h:647
    #6 0x15af88e in fileCoinReadable(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/karas/Cbc/CoinUtils/src/CoinFileIO.cpp:659
    #7 0x16a127e in CoinMpsIO::dealWithFileName(char const*, char const*, CoinFileInput*&) /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:1483:18
    #8 0x16aa2c3 in CoinMpsIO::readMps(char const*, char const*, int&, CoinSet**&) /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:1566:20
    #9 0xc2a8db in OsiClpSolverInterface::readMps(char const*, bool, bool) /home/karas/Cbc/Clp/src/OsiClp/OsiClpSolverInterface.cpp:5765:24
    #10 0x561814 in CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) /home/karas/Cbc/Cbc/src/CbcSolver.cpp:7955:53
    #11 0x5254b6 in main /home/karas/Cbc/Cbc/src/CoinSolve.cpp:350:22
    #12 0x7f29364a51c0 in __libc_start_main /build/glibc-CxtIbX/glibc-2.26/csu/../csu/libc-start.c:308

previously allocated by thread T0 here:
    #0 0x520e30 in operator new(unsigned long) (/home/karas/Cbc/run/bin/cbc+0x520e30)
    #1 0x15af2a2 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.tcc:219:14
    #2 0x15af2a2 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.h:236
    #3 0x15af2a2 in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.h:255
    #4 0x15af2a2 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/basic_string.h:440
    #5 0x15af2a2 in fileCoinReadable(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/karas/Cbc/CoinUtils/src/CoinFileIO.cpp:643
    #6 0x16a127e in CoinMpsIO::dealWithFileName(char const*, char const*, CoinFileInput*&) /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:1483:18
    #7 0x16aa2c3 in CoinMpsIO::readMps(char const*, char const*, int&, CoinSet**&) /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:1566:20
    #8 0xc2a8db in OsiClpSolverInterface::readMps(char const*, bool, bool) /home/karas/Cbc/Clp/src/OsiClp/OsiClpSolverInterface.cpp:5765:24
    #9 0x561814 in CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) /home/karas/Cbc/Cbc/src/CbcSolver.cpp:7955:53
    #10 0x5254b6 in main /home/karas/Cbc/Cbc/src/CoinSolve.cpp:350:22
    #11 0x7f29364a51c0 in __libc_start_main /build/glibc-CxtIbX/glibc-2.26/csu/../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:471:3 in CoinMpsCardReader::~CoinMpsCardReader()
Shadow bytes around the buggy address:
  0x0c0e7fff8330: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fd fd
  0x0c0e7fff8340: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
  0x0c0e7fff8350: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd
  0x0c0e7fff8360: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c0e7fff8370: fd fa fa fa fa fa fd fd fd fd fd fd fd fd fd fa
=>0x0c0e7fff8380:[fa]fa fa fa fd fd fd fd fd fd fd fd fd fa fa fa
  0x0c0e7fff8390: fa fa 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
  0x0c0e7fff83a0: 00 00 00 00 00 00 00 00 04 fa fa fa fa fa fa fa
  0x0c0e7fff83b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0e7fff83c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0e7fff83d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==27178==ABORTING

==========

[Acknowledgement]

This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001,

Innovation hub for high Performance Computing]

[Trac #150] No solution after 12 hours

image

I try to solve a combinatorial problem which has 72562 binary decision variables, annual budget constraints (22 years) and other constraints.

When I set the annual budget as 0 or other small values (non-zero), the solution jumped out very fast. However, when I set the annual budget to a bigger value, it went over 12 hours before I killed it. No solution!

I reduced the number of decision variables, it worked. While, when the number of decision variable increase to 5000, the programme may keep running for long.

Any suggestion? Thank you!

[Trac #167] Crash unless both preprocess and presolve are turned off

image

Attachment(s): https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-167.zip

Running the attached model with default settings yields the following crash:

Welcome to the CBC MILP Solver
Version: 2.9.7
Build Date: Nov 23 2015

command line - cbc-osx/cbc test.mps (default strategy 1)
At line 1 NAME          test
At line 2 ROWS
At line 7 COLUMNS
At line 32 RHS
At line 36 BOUNDS
At line 55 ENDATA
Problem test has 3 rows, 18 columns and 21 elements
Coin0008I test read with 0 errors
libc++abi.dylib: terminating with uncaught exception of type CoinError
[1]    65438 abort      cbc-osx/cbc test.mps

If I turn both preprocess and presolve to off, the model solves as expected, but any other combination of values for these two flags gives the same crash.

The test above was while running on OS X, but it is reproducible on Windows as well.

[Trac #158] Segmentation vialation on infeasible problems

image

Hello.

Running cbc 2.8.12 (could not find in the version list) I have encountered memory violation

Cbc0010I After 204000 nodes, 12 on tree, 3.4028235e+38 best solution, best possible 8073.3801 (1342.74 seconds)
Cbc0010I After 205000 nodes, 11 on tree, 3.4028235e+38 best solution, best possible 8073.3801 (1348.46 seconds)
Cbc0010I After 206000 nodes, 8 on tree, 3.4028235e+38 best solution, best possible 8298.4579 (1354.24 seconds)
Cbc0001I Search completed - best objective 3.402823466385289e+38, took 19355815 iterations and 869001 nodes (1359.25 seconds)
Cbc0032I Strong branching done 171648 times (2422070 iterations), fathomed 4617 nodes and fixed 12697 variables
Cbc0041I Maximum depth 27, 0 variables fixed on reduced cost (662131 nodes in complete fathoming taking 6361958 iterations)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffede6a700 (LWP 26565)]
0x00007ffff0e66be2 in CbcMain1 (argc=3, argv=0x7fffe8134640, model=..., callBack=0x7ffff0e4db85 <dummyCallBack(CbcModel*, int)>, parameterData=...) at CbcSolver.cpp:6641
6641                                                solution2[jColumn] = solution[i];
(gdb) bt
#0  0x00007ffff0e66be2 in CbcMain1 (argc=3, argv=0x7fffe8134640, model=..., callBack=0x7ffff0e4db85 <dummyCallBack(CbcModel*, int)>, parameterData=...) at CbcSolver.cpp:6641
#1  0x00007ffff0e4e1b7 in callCbc1 (input2=0x7ffff1c5124f "-solve", model=..., callBack=0x7ffff0e4db85 <dummyCallBack(CbcModel*, int)>, parameterData=...) at CbcSolver.cpp:1130
#2  0x00007ffff0e4de0a in callCbc (input2=0x7ffff1c5124f "-solve", babSolver=...) at CbcSolver.cpp:1035

In my case a problem was infeasible and bestSolution() == solution == nullptr. Because there is no checks for that in the code above 6641 an attempt to access triggered coredump.

I believe the code connected with solution2 may be simply removed, I saw no usage for solution2. I removed locally and it seemed to work. (if not take into account some asserts i.e.

Cbc0010I After 206000 nodes, 8 on tree, 3.4028235e+38 best solution, best possible 8298.4579 (1356.03 seconds)
Cbc0001I Search completed - best objective 3.402823466385289e+38, took 19355815 iterations and 869001 nodes (1361.02 seconds)
Cbc0032I Strong branching done 171648 times (2422070 iterations), fathomed 4617 nodes and fixed 12697 variables
Cbc0041I Maximum depth 27, 0 variables fixed on reduced cost (662131 nodes in complete fathoming taking 6361958 iterations)
Cgl0013I Postprocessed model is infeasible - possible tolerance issue - try without preprocessing
python: CbcSolver.cpp:6769: int CbcMain1(int, const char**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&): Assertion `saveSolver->isProvenOptimal()' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffede6a700 (LWP 29815)]
0x00007ffff782cbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff782cbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff782ffc8 in __GI_abort () at abort.c:89
#2  0x00007ffff7825a76 in __assert_fail_base (fmt=0x7ffff79772b0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x7ffff279805a <error: Cannot access memory at address 0x7ffff279805a>, file=file@entry=0x7ffff2796e04 <error: Cannot access memory at address 0x7ffff2796e04>, 
    line=line@entry=6769, 
    function=function@entry=0x7ffff2799400 <CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&)::__PRETTY_FUNCTION__> <error: Cannot access memory at address 0x7ffff2799400>) at assert.c:92

)

I hope this information will be helpful. Sorry I can not share exact problem to reproduce because it contains confidential data. The bug triggers very rare; even slightly modified problems passed successfully.

Thanks.

[Trac #151] quadratic objective with cbc

image

Attachments: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-151.zip

Hello,

I read that cbc can solve quadratic problem or I didn't understand.

At the page ​http://www.coin-or.org/Cbc/cbcuserguide.html, point 7, topic Quadratic MIP, it's written "it is possible to do quadratic MIP with CBC". furthermore, Cbc provide some quadratic problem exemples : quad.mps and quad2.mps with the keyword "QUADOBJ".

So, if I try to solve quad.mps I have some problems.

First case (result file : firstcase.txt) : I open cbc with shell and I import quad.mps

Coin:import quad.mps ... Coin:solve ... Result - Optimal solution found

Objective value: 27797.14684147 Enumerated nodes: 30530 Total iterations: 3410826 Time (CPU seconds): 208.77 Time (Wallclock seconds): 210.57

But if I want to print the result I have a segment fault :

Coin:solution solution.txt Erreur de segmentation (core dumped)

Second case (result file : secondcase.txt) : With a command line in the shell, I have no solution :

cbc quad.mps -solution stdout

Welcome to the CBC MILP Solver Version: 2.8 Build Date: May 7 2014 Revision Number: 2031

command line - cbc quad.mps -solution stdout (default strategy 1) At line 1 NAME At line 2 ROWS At line 299 COLUMNS At line 778 RHS At line 878 BOUNDS At line 985 QUADOBJ Problem no_name has 295 rows, 260 columns and 869 elements Coin0008I no_name read with 0 errors At line 1000 ENDATA Status unknown - objective value 0.00000000 Total time (CPU seconds): 0.00 (Wallclock seconds): 0.00

But if and don't ask the solution it seems to work but impossible to know the details of the solution. I added that Gurobi find different objective value (file : gurobi.txt) :

cbc quad.mps

Result - Optimal solution found

Objective value: 27797.14684147 Enumerated nodes: 30530 Total iterations: 3410826 Time (CPU seconds): 208.56 Time (Wallclock seconds): 211.71

Total time (CPU seconds): 208.56 (Wallclock seconds): 211.71

So, is it a bug ? Cbc can solve quadratic model ? Do you have any ideas ?

Thanks for your help and for your work. You provide very good products.

[Trac #172] Maximum Running Time for Infeasible Problem

image

Hello,

I used CbcModel::setMaximumSeconds to set the maximum running time (5-mins) for solving an MILP. When the MILP is feasible (or a feasible solution can be found within the maximum seconds, I guess), the problem can be solved within that running time. However, when the MILP is infeasible, the solver will not return until it determined that the program is infeasible, which takes much longer time than what I wanted. I wonder if there is any option to force the branch and bound solver to return upon the timeout, so that I would be able to take further action with respect to the best possible result.

Thank you.

[Trac #183] Semis section not working as expected.

image

Hi

I am using version 2.9.9 of cbc in ubuntu 17.10 docker image. My test.lp file has following content:

Maximize
 obj: x1 + 2 x2 + 3 x3 + x4
Subject To
 c1: - x1 + x2 + x3 + 10 x4 <= 20
 c2: x1 - 3 x2 + x3 <= 30
 c3: x2 - 3.5 x4 = 0
Bounds
 0 <= x1 <= 40
 2 <= x4 <= 3
General
 x4
Semis
 x1 x2 x3

When trying with semis section i get error "terminate called after throwing an instance of 'CoinError' Aborted"

on mac i get: libc++abi.dylib: terminating with uncaught exception of type CoinError Abort trap: 6

However if I comment out Semis it works fine. I was hoping that Semis are supported. Am I doing something wrong?

My command is : cbc -presolve on -import test.lp solve solu out.txt

On further analysis i found out when in cbc prompt i type "import test.lp" it fails and shows same error is

Thanks

[Trac #176] COIN-OR Cbc FTBFS on mips* platforms due to variable name conflict

image

When compiling cbc 2.9.8 on Linux mips* platforms, an error will be triggered:

 g++ -DHAVE_CONFIG_H -I. -I. -I../src -I/usr/include/coin -I/usr/include/coin/ -DCOIN_NO_CLP_MESSAGE -DUSE_CBCCONFIG -D_FORTIFY_SOURCE=2 -pipe -Wno-error -fstack-protector-strong --param=ssp-buffer-size=4 -fomit-frame-pointer -O3 -mabi=64 -march=mips64r2 -mtune=loongson3a -fira-loop-pressure -fira-hoist-pressure -ftree-vectorize -specs=/usr/lib/autobuild3/specs/hardened-cc1 -fpermissive -fdeclone-ctor-dtor -ftree-vectorize -DCBC_BUILD -MT CbcBranchDynamic.lo -MD -MP -MF .deps/CbcBranchDynamic.Tpo -c CbcBranchDynamic.cpp  -fPIC -DPIC -o .libs/CbcBranchDynamic.o
CbcModel.hpp:2397:78: error: expected ',' or '...' before numeric constant
     void setMIPStart( const std::vector< std::pair< std::string, double > > &mips ) {
                                                                              ^
CbcModel.hpp: In member function 'void CbcModel::setMIPStart(const std::vector<std::pair<std::basic_string<char>, double> >&)':
CbcModel.hpp:2398:26: error: no match for 'operator=' (operand types are 'std::vector<std::pair<std::basic_string<char>, double> >' and 'int')
        this->mipStart_ = mips;
                          ^

Because of the platform Cbc is built on (tested on mipsel and mips64el) it seems that somewhere ahead of this variable name has a constant definition named 'mips', causing 'mips' here be replaced by a "numeric constant" (it might be 1, representing "True").

This problem prevents Cbc from building on mips* platforms. By replacing the variable name (See our patch: ​https://github.com/AOSC-Dev/aosc-os-abbs/blob/staging/extra-scientific/cbc/autobuild/patches/CbcModel-hpp-fix-mips-variable-constant-conflict.patch) this problem can be resolved. Enclosing it.

[Trac #163] CBC doesn't build in VS2013

image

I've been unsuccessful in building CBC using Cbc\stable\2.9\Cbc\MSVisualStudio\v10 with MS Visual Studio 2013. I get two linker errors: Error 59 error LNK2019: unresolved external symbol "int cdecl CbcMain1(int,char const * * const,class CbcModel? &)" (?CbcMain1@@YAHHQAPBDAAVCbcModel@@@z) referenced in function _Cbc_solve@4 C:\Projects\Cbc\stable\2.9\Cbc\MSVisualStudio\v9\cbcCInterfaceDll\Cbc_C_Interface.obj cbcCInterfaceDll

and

Error 58 error LNK2019: unresolved external symbol "void cdecl CbcMain0(class CbcModel? &)" (?CbcMain0@@YAXAAVCbcModel@@@z) referenced in function _Cbc_newModel@0 C:\Projects\Cbc\stable\2.9\Cbc\MSVisualStudio\v9\cbcCInterfaceDll\Cbc_C_Interface.obj cbcCInterfaceDll

Nor can I find the CBC binaries for windows for recent versions at

http://www.coin-or.org/Binaries/Cbc/

Nor do the older versions of those binaries contain what I think are the cbc dll's referred to in ticket #99 for use with other projects.

=========================

I've managed to build the C interface DLL using the MSVC 2015 build tools. You need to make the following change in cbcCInterfaceDll.vcxproj:

Change:

<AdditionalDependencies?>libOsiClp.lib;%(AdditionalDependencies?)</AdditionalDependencies?>

To:

<AdditionalDependencies?>libCbcSolver.lib;libCbc.lib;libCgl.lib;libOsiClp.lib;libOsi.lib;libClp.lib;libCoinUtils.lib;%(AdditionalDependencies?)</AdditionalDependencies?>

There are 4 instances to replace (one for each build target).

I built this using the command line tools. You need to re-enable this project in the solution file.

msbuild Cbc.sln /p:PlatformToolset=v140 /p:Configuration=Release /p:Platform=x64

The resulting DLL seems to function as expected. I'm using it from Python with the ctypes library.

[Trac #138] writeMps() bug?

image

I am quite new to coin-or, so I might be wrong, yet there seems to be a bug regarding the writeMps() method.

Scenario: My objective function a quite simple minimization problem over a number of days, where I'd like to choose the earliest periods for each day. (Min Z = sum_days sum_periods p * choose_d,p )

For 2 days and 2 periods with indices {0,1}, that would equal 4 column with values {0,1,0,1}

The model works fine, yet when I try to print write the model to an mps file, the first column is omitted. Thus, reading it later will create another (incorrect) answer.

As the model is so simple, I just modified the coefficient to (p+1) as soon as I found the reason my answers were all wrong, yet I thought I'd at least should at least report this incident as a bug.

More install issues

Even with #11 there are still some install issues without svn.

Missing --git

Besides the .sh there is a missing --git in the Install instructions:

git clone --branch=stable/2.9 https://github.com/coin-or/Cbc Cbc-2.9
cd Cbc-2.9
git clone --branch=stable/0.8 https://github.com/coin-or-tools/BuildTools
BuildTools/get.dependencies.sh fetch

yields

Checkout ThirdParty/ASL
BuildTools/get.dependencies.sh: line 228: svn: command not found

Data dependencies still use svn with --git

Running with --git still uses svn:

git clone --branch=stable/2.9 https://github.com/coin-or/Cbc Cbc-2.9
cd Cbc-2.9
git clone --branch=stable/0.8 https://github.com/coin-or-tools/BuildTools
BuildTools/get.dependencies.sh fetch --git

yields

Verify that there are no error message in the output above.
/home/jvielma/delme/Cbc-2.9
Checkout Data/Sample
BuildTools/get.dependencies.sh: line 271: svn: command not found

Nested directories for some packages

After deleting lines 8-9 of Dependencies getting dependencies through

git clone --branch=stable/2.9 https://github.com/coin-or/Cbc Cbc-2.9
cd Cbc-2.9
git clone --branch=stable/0.8 https://github.com/coin-or-tools/BuildTools
BuildTools/get.dependencies.sh fetch --git

works, but after that

mkdir build
cd build
../configure

yields

checking for COIN-OR package CoinUtils... not given: No package 'coinutils' found
configure: error: Required package CoinUtils not available.
configure: error: /bin/bash '../../../Osi/Osi/configure' failed for Osi
configure: error: /bin/bash '../../Osi/configure' failed for Osi

The source of the problem seems to be that the github version of some packages have a nested structure that is not present in the svn versions (e.g. Osi directory inside of Osi directory). After eliminating this nested structure (e.g. with the script below) configure and make work (testing fails if the data dependencies are eliminated from Dependencies as described above.

for i in {CoinUtils,Clp,Cgl,Osi}; do 
   mv $i ${i}.old; 
   mv ${i}.old/${i} $i; 
done

[Trac #155] OsiCbc warning is sent to stdout, not stderr

image

Specifically,

Warning: Use of OsiCbc is deprecated. To enjoy the full performance of Cbc, use the CbcSolver interface.

should likely be sent to stderr.

I don't know enough about how the message handler works, but the OsiCbc warning is printed to stdout even if the log level is 0.

[Trac #157] CoinMP: CoinMP.CoinReadFile unfinished ?

image

Hello, I only wanted to know if the read MPS function call in CoinMP is supposed to be working or not.

When I use it, if doesn't fill the structure PPROBLEM is pointing to.

Cannot find any code in the source to do that as well.

Thanks a lot Leo

[Trac #142] Problem dsbmip takes half an hour in -miplib unit test with GCC 4.4 or older

image

Mostly a heads-up, since Data/miplib3 is only getting used by Cbc/trunk and in CoinAll. When compiled with GCC 4.4.x (or older, also happened for 4.1.2), the dsbmip problem takes half an hour during make test where it only takes about 20 seconds with GCC 4.6.4 or 4.8.x. Oddly just calling ./cbc ../Data/miplib3/dsbmip.gz (from installed build/bin folder) solves the problem in less than a second, but calling ./cbc -miplib appears to change the options in some way that causes a very long runtime for this problem with older GCC versions. Might be something to look into, or at least make a note of.

Here are some make test logs for comparison GCC 4.6.3 ​https://gist.github.com/7671984 GCC 4.4.7 ​https://gist.github.com/7672197 GCC 4.5.3 ​https://gist.github.com/7671988 Clang 3.3, Clang++ 3.3, Gfortran 4.6.3 ​https://gist.github.com/7671977

[Trac #147] Potential race hazard in cbc

image

Attachments: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-147.zip

Running cbc on the attached problem multiple times with threads set to the number of cores produces different results. All cuts, heuristics and preprocessing are turned off. Attached is a script which runs the problem repeatedly until it finds a discrepancy. Removing the threads option produces the same right answer when rerun. I've configured cbc using the --enable-cbc-parallel, --disable-shared and --enable-static flags. I've tried different versions of cbc (2.8 and 2.8.9) and the issue is reproducible with all of them. Tested on Ubuntu 12.04.

[Trac #141] patch to include cstddef headers

image
image

What OS/distribution is having trouble? Cbc current trunk has no problems building for me with GCC 4.8.0 on a Red Hat machine. Also works fine straight from trunk, no modifications, on Ubuntu 13.10 with GCC 4.8.1.

[Trac #179] multiThreadind and algorithms options

image

Hello everybody,

I'm sorry to bother with this ticket, but I didn't find any forum where I can question a CBC developer.

We're using with my team the CBC solver on a big logistic problem (around 4 millions continuous and discrete variables).

We observed that when we launch the solving directly from command lines it is way quicker than from our project execution (c++).

In both cases we would like first to know how can we activate the multithreading option because for the moment it runs with only one thread. I read that it could be a problem of the way we compiled the solver ?!

Then, is someone know if there is any option we can activate in our c++ project in order to use the same algorithms as command line ones (in our project "cgl" and "cbc" algorithms are launched whereas in command line "clp" is).

I would be very grateful is someone can help.

Regards,

Leslie

[Trac #168] long postprocessing

image

Attachment(s): https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-168.zip

If I run the attached instance with a timelimit of 520 seconds, the current Cbc stable/2.9 (rev 2279) takes very long in postprocessing.

That is, there are lines like

Cbc0003I Exiting on maximum nodes
Cbc0005I Partial search - best objective 1e+50 (best possible -38096162), took 10927 iterations and 200 nodes (343.07 seconds)
...
Cbc0005I Partial search - best objective -37399096 (best possible -38600836), took 0 iterations and 0 nodes (412.40 seconds)

in the output, but after printing

Cgl0014I Postprocessing changed objective from -37399091 to -37399098 - possible tolerance issue - try without preprocessing

it takes very long to terminate.

Also the final summary indicates that Cbc spend more than an hour for the postprocessing, even though it has already almost hit the timelimit before that:

Time (CPU seconds):             4559.80
Time (Wallclock seconds):       4568.20

Total time (CPU seconds):       4562.79   (Wallclock seconds):       4571.37

I attach the MPS file and a log from running with -loglevel 4.

[Trac #169] different objective value for equivalent models

image

Attachment(s): https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-169.zip

Hi,

I have two IP models that should have the same optimal objective value judging from the way they are created, and in fact another MILP solver gives me an objective of -176.0 for both. Cbc (used through NEOS and also through google's or-tools' JAVA interface) gives me -175.0 and -176.0 respectively.

Is there any suggestion on what I am missing here? I attach mps and lp files for both models.

Thanks, Sven

[Trac #165] Command line CBC reports "Optimal solution found", but the solution file reports "Status unknown"

image

Attachments: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-165.zip

Hello,

I have a problem where the command line reports "Optimal solution found", with a reasonable objective value, but in the solution file "Status unknown" is reported. CBC has been compiled with MinGW 4.9.2, and works quite well with many other problems. The command line parameters are:

cbc -import pcbc.lp -solve -solution pcbc.sol -quit

By using:

cbc -import pcbc.lp -perturbation off -solve -solution pcbc.sol -quit

I get rid of some infeasibility warnings, the problem get solved to the same exact objective, but the solution file now is correct, so probably it is just a minor problem in the output procedure.

Attached the sample problem.

Thanks in advance for your attention, and thanks also for the excellent work.

[Trac #156] Cbc-infeasible Cplex&GLPK-feasible

image

Attachments: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-156.zip

Hello all,

I’m having issues solving my model with Cbc. Attached you can find the mps. GLPK and Cplex find feasible solutions. Cplex finds the optimal solution within a minute, while GLPK needs several hours to find a decent solution.

Cbc results:

Continuous objective value is 122787 - 0.61 seconds Cgl0003I 7 fixed, 0 tightened bounds, 321 strengthened rows, 0 substitutions Cgl0000I Cut generators found to be infeasible! (or unbounded) Pre-processing says infeasible or unbounded

When setting the parameters presolve and preprocess to off, Cbc (sometimes) finds an optimal solution with objective value 480069. However, the solution provided by Cplex is 300274.

Do you know why cbc fails to solve this problem to optimality?

[Trac #180] NULL pointer dereference in CoinMpsIO::rowName

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-180.zip

Hello.

I found a NULL pointer dereference in cbc.

Please confirm.

Thanks.

Summary: NULL pointer dereference

OS: CentOS 7 64bit

Version: Trunk (unstable)

PoC Download: ​https://github.com/gy741/PoC/raw/master/Null_CoinMpsIO_rowName

Steps to reproduce: 1.Download the .POC files. 2.Compile the source code with ASan. 3.Execute the following command : ./cbc $POC

ASAN:SIGSEGV
=================================================================
==20322==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f3612a0441d bp 0x7ffc1b7494f0 sp 0x7ffc1b748e90 T0)
    #0 0x7f3612a0441c in CoinMpsIO::rowName(int) const /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:5168:12
    #1 0x7f3614a2dff7 in OsiClpSolverInterface::readMps(char const*, bool, bool) /home/karas/Cbc/Clp/src/OsiClp/OsiClpSolverInterface.cpp:5828:22
    #2 0x7f3615a51a86 in CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) /home/karas/Cbc/Cbc/src/CbcSolver.cpp:7955:42
    #3 0x4dcfd2 in main /home/karas/Cbc/Cbc/src/CoinSolve.cpp:350:22
    #4 0x7f360f8bf82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
    #5 0x435a18 in _start (/home/karas/Cbc/qq/bin/cbc+0x435a18)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home//karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:5168 CoinMpsIO::rowName(int) const
==20322==ABORTING

==========

[Acknowledgement]

This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001,

Innovation hub for high Performance Computing]

[Trac #144] Crash of 2.8.8

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-144.zip

Hi

I updated from 2.8.3 to 2.8.8. After that cbc crash after 16'000 seconds without error message, with version 2.8.3 the same mps file works.

I'm not a mathematician, but the developer, so I have no clue about the content of the attached mps file which cause the crash.

This is the log content:

Welcome to the CBC MILP Solver Version: 2.8.8 Build Date: Jan 23 2014 Revision Number: 2004 command line - cbc /tmp/2036-pulp.mps ratio 0.0001 sec 36000.0 branch printingOptions rows solution /tmp/2036-pulp.sol (default strategy 1) At line 2 NAME MODEL At line 3 ROWS At line 10016 COLUMNS At line 700133 RHS At line 710145 BOUNDS At line 745742 ENDATA Problem MODEL has 10011 rows, 35754 columns and 618766 elements Coin0008I MODEL read with 0 errors ratioGap was changed from 0 to 0.0001 seconds was changed from 1e+100 to 36000 Continuous objective value is 4279.21 - 11.51 seconds Cgl0003I 420 fixed, 0 tightened bounds, 743 strengthened rows, 159 substitutions Cgl0003I 26 fixed, 0 tightened bounds, 344 strengthened rows, 9 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 305 strengthened rows, 4 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 458 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 312 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 223 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 163 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 146 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 75 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 66 strengthened rows, 0 substitutions Cgl0003I 0 fixed, 0 tightened bounds, 66 strengthened rows, 0 substitutions Cgl0004I processed model has 6935 rows, 20001 columns (19843 integer) and 563183 elements Cbc0038I Pass 1: (62.37 seconds) suminf. 84.31250 (221) obj. 10922.7 iterations 16322 Cbc0038I Pass 2: (62.68 seconds) suminf. 51.97917 (148) obj. 11284.6 iterations 831 Cbc0038I Pass 3: (62.75 seconds) suminf. 51.97917 (148) obj. 11284.6 iterations 36 Cbc0038I Pass 4: (62.85 seconds) suminf. 32.85417 (112) obj. 11433.1 iterations 163 Cbc0038I Pass 5: (63.00 seconds) suminf. 28.47917 (94) obj. 11487.4 iterations 174 Cbc0038I Pass 6: (63.06 seconds) suminf. 25.97917 (89) obj. 11501.1 iterations 12 Cbc0038I Pass 7: (63.12 seconds) suminf. 25.97917 (89) obj. 11501.1 iterations 2 Cbc0038I Pass 8: (63.20 seconds) suminf. 21.47917 (75) obj. 11632.7 iterations 70 Cbc0038I Pass 9: (63.27 seconds) suminf. 15.97917 (64) obj. 11678.8 iterations 88 Cbc0038I Pass 10: (63.33 seconds) suminf. 15.97917 (64) obj. 11678.8 iterations 18 Cbc0038I Pass 11: (63.47 seconds) suminf. 9.56250 (41) obj. 11769 iterations 229 Cbc0038I Pass 12: (63.53 seconds) suminf. 7.06250 (36) obj. 11773 iterations 28 Cbc0038I Pass 13: (63.59 seconds) suminf. 7.06250 (36) obj. 11773 iterations 1 Cbc0038I Pass 14: (63.72 seconds) suminf. 2.50000 (5) obj. 11787.7 iterations 218 Cbc0038I Pass 15: (63.78 seconds) suminf. 0.00000 (0) obj. 11781.9 iterations 33 Cbc0038I Solution found of 11781.9 Cbc0038I Before mini branch and bound, 18207 integers at bound fixed and 0 continuous Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1509 rows 1218 columns Cbc0038I Mini branch and bound improved solution from 11781.9 to 8873.09 (68.33 seconds) Cbc0038I Round again with cutoff of 8441.75 Cbc0038I Pass 16: (70.32 seconds) suminf. 134.18176 (399) obj. 8441.75 iterations 2344 Cbc0038I Pass 17: (71.23 seconds) suminf. 93.69322 (370) obj. 8441.75 iterations 1970 Cbc0038I Pass 18: (71.82 seconds) suminf. 77.61653 (308) obj. 8441.75 iterations 1279 Cbc0038I Pass 19: (72.17 seconds) suminf. 69.88408 (302) obj. 8441.75 iterations 546 Cbc0038I Pass 20: (72.76 seconds) suminf. 67.41632 (301) obj. 8441.75 iterations 861 Cbc0038I Pass 21: (73.09 seconds) suminf. 63.54054 (286) obj. 8441.75 iterations 400 Cbc0038I Pass 22: (73.30 seconds) suminf. 63.49674 (291) obj. 8441.75 iterations 302 Cbc0038I Pass 23: (73.49 seconds) suminf. 60.70313 (282) obj. 8441.75 iterations 223 Cbc0038I Pass 24: (73.76 seconds) suminf. 60.03537 (277) obj. 8441.75 iterations 349 Cbc0038I Pass 25: (74.07 seconds) suminf. 59.86139 (273) obj. 8441.75 iterations 345 Cbc0038I Pass 26: (74.26 seconds) suminf. 57.46451 (268) obj. 8441.75 iterations 172 Cbc0038I Pass 27: (74.41 seconds) suminf. 57.46451 (268) obj. 8441.75 iterations 108 Cbc0038I Pass 28: (74.52 seconds) suminf. 57.46451 (268) obj. 8441.75 iterations 32 Cbc0038I Pass 29: (75.93 seconds) suminf. 56.00216 (210) obj. 8441.75 iterations 2623 Cbc0038I Pass 30: (76.85 seconds) suminf. 44.98941 (237) obj. 8441.75 iterations 1997 Cbc0038I Pass 31: (77.26 seconds) suminf. 43.33932 (230) obj. 8441.75 iterations 725 Cbc0038I Pass 32: (77.40 seconds) suminf. 43.33932 (230) obj. 8441.75 iterations 110 Cbc0038I Pass 33: (77.51 seconds) suminf. 43.33932 (230) obj. 8441.75 iterations 69 Cbc0038I Pass 34: (77.65 seconds) suminf. 43.33932 (230) obj. 8441.75 iterations 101 Cbc0038I Pass 35: (78.99 seconds) suminf. 46.94591 (170) obj. 8441.75 iterations 2703 Cbc0038I Pass 36: (79.70 seconds) suminf. 41.80765 (201) obj. 8441.75 iterations 1284 Cbc0038I Pass 37: (79.89 seconds) suminf. 41.70040 (204) obj. 8441.75 iterations 247 Cbc0038I Pass 38: (80.06 seconds) suminf. 41.49570 (200) obj. 8441.75 iterations 168 Cbc0038I Pass 39: (80.22 seconds) suminf. 40.70970 (192) obj. 8441.75 iterations 146 Cbc0038I Pass 40: (80.37 seconds) suminf. 40.70970 (192) obj. 8441.75 iterations 117 Cbc0038I Pass 41: (80.53 seconds) suminf. 40.70970 (192) obj. 8441.75 iterations 133 Cbc0038I Pass 42: (80.64 seconds) suminf. 38.13931 (187) obj. 8441.75 iterations 63 Cbc0038I Pass 43: (80.74 seconds) suminf. 38.13931 (187) obj. 8441.75 iterations 32 Cbc0038I Pass 44: (80.84 seconds) suminf. 38.13931 (187) obj. 8441.75 iterations 27 Cbc0038I Pass 45: (80.95 seconds) suminf. 38.13931 (187) obj. 8441.75 iterations 59 Cbc0038I No solution found this major pass Cbc0038I Before mini branch and bound, 17992 integers at bound fixed and 0 continuous Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1655 rows 1433 columns Cbc0038I Mini branch and bound did not improve solution (85.64 seconds) Cbc0038I After 85.64 seconds - Feasibility pump exiting with objective of 8873.09 - took 32.33 seconds Cbc0012I Integer solution of 8873.0949 found by feasibility pump after 0 iterations and 0 nodes (86.49 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1331 rows 1030 columns Cbc0012I Integer solution of 8809.1339 found by RINS after 0 iterations and 0 nodes (103.94 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 0 rows 0 columns Cbc0031I 625 added rows had average density of 131.3312 Cbc0013I At root node, 625 cuts changed objective from 4559.6113 to 7204.3443 in 20 passes Cbc0014I Cut generator 0 (Probing) - 172 row cuts average 40.0 elements, 1 column cuts (293 active) in 1.996 seconds - new frequency is -100 Cbc0014I Cut generator 1 (Gomory) - 7498 row cuts average 247.1 elements, 0 column cuts (0 active) in 17.413 seconds - new frequency is 1 Cbc0014I Cut generator 2 (Knapsack) - 32 row cuts average 23.8 elements, 0 column cuts (0 active) in 0.380 seconds - new frequency is -100 Cbc0014I Cut generator 3 (Clique) - 46 row cuts average 4.2 elements, 0 column cuts (0 active) in 0.196 seconds - new frequency is -100 Cbc0014I Cut generator 4 (MixedIntegerRounding2) - 181 row cuts average 135.0 elements, 0 column cuts (0 active) in 61.600 seconds - new frequency is -100 Cbc0014I Cut generator 6 (TwoMirCuts?) - 4335 row cuts average 130.6 elements, 0 column cuts (0 active) in 9.249 seconds - new frequency is 1 Cbc0010I After 0 nodes, 1 on tree, 8809.1339 best solution, best possible 7204.3443 (306.65 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1392 rows 1276 columns Cbc0012I Integer solution of 8045.072 found by RINS after 74287 iterations and 41 nodes (406.47 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 435 rows 386 columns Cbc0012I Integer solution of 8044.5555 found by combine solutions after 74287 iterations and 41 nodes (410.52 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1172 rows 1068 columns Cbc0012I Integer solution of 8042.6851 found by RINS after 86324 iterations and 91 nodes (492.42 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 529 rows 439 columns Cbc0012I Integer solution of 8006.8948 found by combine solutions after 86324 iterations and 91 nodes (498.10 seconds) Cbc0010I After 100 nodes, 59 on tree, 8006.8948 best solution, best possible 7204.3443 (508.13 seconds) Cbc0010I After 200 nodes, 109 on tree, 8006.8948 best solution, best possible 7204.3443 (621.34 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1177 rows 1085 columns Cbc0010I After 300 nodes, 159 on tree, 8006.8948 best solution, best possible 7204.3443 (751.23 seconds) Cbc0010I After 400 nodes, 208 on tree, 8006.8948 best solution, best possible 7204.3443 (875.33 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1192 rows 1092 columns Cbc0010I After 500 nodes, 258 on tree, 8006.8948 best solution, best possible 7204.3443 (1026.98 seconds) Cbc0010I After 600 nodes, 309 on tree, 8006.8948 best solution, best possible 7204.3443 (1159.56 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1205 rows 1117 columns Cbc0010I After 700 nodes, 357 on tree, 8006.8948 best solution, best possible 7204.3443 (1303.07 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1180 rows 1095 columns Cbc0010I After 800 nodes, 408 on tree, 8006.8948 best solution, best possible 7204.3443 (1449.64 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1227 rows 1142 columns Cbc0012I Integer solution of 7997.3774 found by RINS after 306772 iterations and 900 nodes (1596.53 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 587 rows 469 columns Cbc0012I Integer solution of 7995.6339 found by combine solutions after 306772 iterations and 900 nodes (1602.36 seconds) Cbc0010I After 900 nodes, 457 on tree, 7995.6339 best solution, best possible 7204.3443 (1602.37 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1168 rows 1057 columns Cbc0010I After 1000 nodes, 507 on tree, 7995.6339 best solution, best possible 7204.3443 (1739.52 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1378 rows 1272 columns Cbc0010I After 1100 nodes, 606 on tree, 7995.6339 best solution, best possible 7204.3443 (1880.15 seconds) Cbc0010I After 1200 nodes, 706 on tree, 7995.6339 best solution, best possible 7204.3443 (1986.57 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1192 rows 1074 columns Cbc0010I After 1300 nodes, 806 on tree, 7995.6339 best solution, best possible 7204.3443 (2093.77 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1122 rows 1015 columns Cbc0010I After 1400 nodes, 906 on tree, 7995.6339 best solution, best possible 7204.3443 (2192.15 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1052 rows 936 columns Cbc0010I After 1500 nodes, 1006 on tree, 7995.6339 best solution, best possible 7204.3443 (2283.99 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1016 rows 899 columns Cbc0012I Integer solution of 7987.8936 found by RINS after 420158 iterations and 1600 nodes (2359.69 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 741 rows 602 columns Cbc0012I Integer solution of 7967.7643 found by combine solutions after 420158 iterations and 1600 nodes (2367.46 seconds) Cbc0010I After 1600 nodes, 1106 on tree, 7967.7643 best solution, best possible 7204.3443 (2367.46 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1188 rows 1078 columns Cbc0010I After 1700 nodes, 1156 on tree, 7967.7643 best solution, best possible 7204.3443 (2506.94 seconds) Cbc0010I After 1800 nodes, 1206 on tree, 7967.7643 best solution, best possible 7204.3443 (2629.66 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1245 rows 1144 columns Cbc0010I After 1900 nodes, 1256 on tree, 7967.7643 best solution, best possible 7204.3443 (2797.47 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1252 rows 1156 columns Cbc0010I After 2000 nodes, 1306 on tree, 7967.7643 best solution, best possible 7204.3443 (2952.56 seconds) Cbc0010I After 2100 nodes, 1357 on tree, 7967.7643 best solution, best possible 7204.3443 (3064.50 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1244 rows 1146 columns Cbc0010I After 2200 nodes, 1406 on tree, 7967.7643 best solution, best possible 7204.3443 (3205.94 seconds) Cbc0010I After 2300 nodes, 1455 on tree, 7967.7643 best solution, best possible 7204.3443 (3328.53 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1277 rows 1181 columns Cbc0010I After 2400 nodes, 1504 on tree, 7967.7643 best solution, best possible 7204.3443 (3477.90 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1241 rows 1144 columns Cbc0010I After 2500 nodes, 1553 on tree, 7967.7643 best solution, best possible 7204.3443 (3612.75 seconds) Cbc0010I After 2600 nodes, 1600 on tree, 7967.7643 best solution, best possible 7204.3443 (3727.58 seconds) Cbc0010I After 2700 nodes, 1648 on tree, 7967.7643 best solution, best possible 7204.3443 (3847.37 seconds) Cbc0010I After 2800 nodes, 1697 on tree, 7967.7643 best solution, best possible 7204.3443 (3961.80 seconds) Cbc0010I After 2900 nodes, 1743 on tree, 7967.7643 best solution, best possible 7204.3443 (4075.60 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1267 rows 1172 columns Cbc0010I After 3000 nodes, 1792 on tree, 7967.7643 best solution, best possible 7204.3443 (4212.29 seconds) Cbc0010I After 3100 nodes, 1840 on tree, 7967.7643 best solution, best possible 7204.3443 (4324.78 seconds) Cbc0010I After 3200 nodes, 1887 on tree, 7967.7643 best solution, best possible 7204.3443 (4438.46 seconds) Cbc0010I After 3300 nodes, 1936 on tree, 7967.7643 best solution, best possible 7204.3443 (4546.47 seconds) Cbc0010I After 3400 nodes, 1985 on tree, 7967.7643 best solution, best possible 7204.3443 (4656.03 seconds) Cbc0010I After 3500 nodes, 2033 on tree, 7967.7643 best solution, best possible 7204.3443 (4765.93 seconds) Cbc0010I After 3600 nodes, 2080 on tree, 7967.7643 best solution, best possible 7204.3443 (4893.39 seconds) Cbc0010I After 3700 nodes, 2128 on tree, 7967.7643 best solution, best possible 7204.3443 (5004.20 seconds) Cbc0010I After 3800 nodes, 2177 on tree, 7967.7643 best solution, best possible 7204.3443 (5116.47 seconds) Cbc0010I After 3900 nodes, 2226 on tree, 7967.7643 best solution, best possible 7204.3443 (5238.09 seconds) Cbc0010I After 4000 nodes, 2272 on tree, 7967.7643 best solution, best possible 7204.3443 (5345.57 seconds) Cbc0010I After 4100 nodes, 2321 on tree, 7967.7643 best solution, best possible 7204.3443 (5452.57 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1302 rows 1219 columns Cbc0010I After 4200 nodes, 2367 on tree, 7967.7643 best solution, best possible 7204.3443 (5598.30 seconds) Cbc0010I After 4300 nodes, 2418 on tree, 7967.7643 best solution, best possible 7204.3443 (5710.66 seconds) Cbc0010I After 4400 nodes, 2464 on tree, 7967.7643 best solution, best possible 7204.3443 (5813.71 seconds) Cbc0010I After 4500 nodes, 2513 on tree, 7967.7643 best solution, best possible 7204.3443 (5935.79 seconds) Cbc0010I After 4600 nodes, 2559 on tree, 7967.7643 best solution, best possible 7204.3443 (6042.70 seconds) Cbc0010I After 4700 nodes, 2609 on tree, 7967.7643 best solution, best possible 7204.3443 (6167.11 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1262 rows 1172 columns Cbc0010I After 4800 nodes, 2659 on tree, 7967.7643 best solution, best possible 7204.3443 (6306.40 seconds) Cbc0010I After 4900 nodes, 2705 on tree, 7967.7643 best solution, best possible 7204.3443 (6425.83 seconds) Cbc0010I After 5000 nodes, 2753 on tree, 7967.7643 best solution, best possible 7204.3443 (6538.28 seconds) Cbc0010I After 5100 nodes, 2851 on tree, 7967.7643 best solution, best possible 7204.3443 (6634.45 seconds) Cbc0010I After 5200 nodes, 2951 on tree, 7967.7643 best solution, best possible 7204.3443 (6733.32 seconds) Cbc0010I After 5300 nodes, 3049 on tree, 7967.7643 best solution, best possible 7204.3443 (6814.35 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 934 rows 815 columns Cbc0012I Integer solution of 7967.7052 found by RINS after 1565059 iterations and 5400 nodes (6876.17 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 793 rows 652 columns Cbc0012I Integer solution of 7966.3672 found by combine solutions after 1565059 iterations and 5400 nodes (6888.66 seconds) Cbc0010I After 5400 nodes, 3147 on tree, 7966.3672 best solution, best possible 7204.3443 (6888.66 seconds) Cbc0010I After 5500 nodes, 3196 on tree, 7966.3672 best solution, best possible 7204.3443 (7007.37 seconds) Cbc0010I After 5600 nodes, 3246 on tree, 7966.3672 best solution, best possible 7204.3443 (7128.01 seconds) Cbc0010I After 5700 nodes, 3292 on tree, 7966.3672 best solution, best possible 7204.3443 (7240.14 seconds) Cbc0010I After 5800 nodes, 3339 on tree, 7966.3672 best solution, best possible 7204.3443 (7362.53 seconds) Cbc0010I After 5900 nodes, 3388 on tree, 7966.3672 best solution, best possible 7204.3443 (7471.62 seconds) Cbc0010I After 6000 nodes, 3437 on tree, 7966.3672 best solution, best possible 7204.3443 (7597.64 seconds) Cbc0010I After 6100 nodes, 3485 on tree, 7966.3672 best solution, best possible 7204.3443 (7712.79 seconds) Cbc0010I After 6200 nodes, 3534 on tree, 7966.3672 best solution, best possible 7204.3443 (7819.16 seconds) Cbc0010I After 6300 nodes, 3582 on tree, 7966.3672 best solution, best possible 7204.3443 (7935.24 seconds) Cbc0010I After 6400 nodes, 3631 on tree, 7966.3672 best solution, best possible 7204.3443 (8055.88 seconds) Cbc0010I After 6500 nodes, 3681 on tree, 7966.3672 best solution, best possible 7204.3443 (8164.79 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1307 rows 1206 columns Cbc0010I After 6600 nodes, 3726 on tree, 7966.3672 best solution, best possible 7204.3443 (8307.27 seconds) Cbc0010I After 6700 nodes, 3776 on tree, 7966.3672 best solution, best possible 7204.3443 (8422.55 seconds) Cbc0010I After 6800 nodes, 3822 on tree, 7966.3672 best solution, best possible 7204.3443 (8537.19 seconds) Cbc0010I After 6900 nodes, 3871 on tree, 7966.3672 best solution, best possible 7204.3443 (8644.81 seconds) Cbc0010I After 7000 nodes, 3921 on tree, 7966.3672 best solution, best possible 7204.3443 (8761.15 seconds) Cbc0010I After 7100 nodes, 3971 on tree, 7966.3672 best solution, best possible 7204.3443 (8872.54 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1286 rows 1192 columns Cbc0010I After 7200 nodes, 4022 on tree, 7966.3672 best solution, best possible 7204.3443 (9019.06 seconds) Cbc0010I After 7300 nodes, 4070 on tree, 7966.3672 best solution, best possible 7204.3443 (9137.37 seconds) Cbc0010I After 7400 nodes, 4119 on tree, 7966.3672 best solution, best possible 7204.3443 (9263.36 seconds) Cbc0010I After 7500 nodes, 4167 on tree, 7966.3672 best solution, best possible 7204.3443 (9378.36 seconds) Cbc0010I After 7600 nodes, 4216 on tree, 7966.3672 best solution, best possible 7204.3443 (9503.56 seconds) Cbc0010I After 7700 nodes, 4265 on tree, 7966.3672 best solution, best possible 7204.3443 (9627.24 seconds) Cbc0010I After 7800 nodes, 4312 on tree, 7966.3672 best solution, best possible 7204.3443 (9742.72 seconds) Cbc0010I After 7900 nodes, 4361 on tree, 7966.3672 best solution, best possible 7204.3443 (9859.80 seconds) Cbc0010I After 8000 nodes, 4410 on tree, 7966.3672 best solution, best possible 7204.3443 (9985.33 seconds) Cbc0010I After 8100 nodes, 4460 on tree, 7966.3672 best solution, best possible 7204.3443 (10100.40 seconds) Cbc0010I After 8200 nodes, 4506 on tree, 7966.3672 best solution, best possible 7204.3443 (10218.29 seconds) Cbc0010I After 8300 nodes, 4554 on tree, 7966.3672 best solution, best possible 7204.3443 (10333.41 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1287 rows 1212 columns Cbc0010I After 8400 nodes, 4601 on tree, 7966.3672 best solution, best possible 7204.3443 (10477.51 seconds) Cbc0010I After 8500 nodes, 4651 on tree, 7966.3672 best solution, best possible 7204.3443 (10596.83 seconds) Cbc0010I After 8600 nodes, 4696 on tree, 7966.3672 best solution, best possible 7204.3443 (10712.77 seconds) Cbc0010I After 8700 nodes, 4744 on tree, 7966.3672 best solution, best possible 7204.3443 (10831.56 seconds) Cbc0010I After 8800 nodes, 4795 on tree, 7966.3672 best solution, best possible 7204.3443 (10943.71 seconds) Cbc0010I After 8900 nodes, 4844 on tree, 7966.3672 best solution, best possible 7204.3443 (11062.34 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1320 rows 1227 columns Cbc0012I Integer solution of 7966.2812 found by RINS after 2735503 iterations and 9000 nodes (11218.43 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 822 rows 677 columns Cbc0012I Integer solution of 7965.8969 found by combine solutions after 2735503 iterations and 9000 nodes (11230.33 seconds) Cbc0010I After 9000 nodes, 4893 on tree, 7965.8969 best solution, best possible 7204.3443 (11230.33 seconds) Cbc0010I After 9100 nodes, 4992 on tree, 7965.8969 best solution, best possible 7204.3443 (11327.02 seconds) Cbc0010I After 9200 nodes, 5092 on tree, 7965.8969 best solution, best possible 7204.3443 (11415.02 seconds) Cbc0010I After 9300 nodes, 5192 on tree, 7965.8969 best solution, best possible 7204.3443 (11481.31 seconds) Cbc0010I After 9400 nodes, 5292 on tree, 7965.8969 best solution, best possible 7204.3443 (11538.51 seconds) Cbc0010I After 9500 nodes, 5392 on tree, 7965.8969 best solution, best possible 7204.3443 (11592.41 seconds) Cbc0010I After 9600 nodes, 5446 on tree, 7965.8969 best solution, best possible 7204.3443 (11639.62 seconds) Cbc0010I After 9700 nodes, 5432 on tree, 7965.8969 best solution, best possible 7204.3443 (11679.40 seconds) Cbc0010I After 9800 nodes, 5433 on tree, 7965.8969 best solution, best possible 7204.3443 (11724.59 seconds) Cbc0010I After 9900 nodes, 5419 on tree, 7965.8969 best solution, best possible 7204.3443 (11768.29 seconds) Cbc0010I After 10000 nodes, 5431 on tree, 7965.8969 best solution, best possible 7204.3443 (11815.09 seconds) Cbc0010I After 10100 nodes, 5433 on tree, 7965.8969 best solution, best possible 7204.3443 (11863.40 seconds) Cbc0010I After 10200 nodes, 5441 on tree, 7965.8969 best solution, best possible 7204.3443 (11911.36 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 918 rows 781 columns Cbc0010I After 10300 nodes, 5413 on tree, 7965.8969 best solution, best possible 7204.3443 (11959.65 seconds) Cbc0010I After 10400 nodes, 5425 on tree, 7965.8969 best solution, best possible 7204.3443 (12003.34 seconds) Cbc0010I After 10500 nodes, 5407 on tree, 7965.8969 best solution, best possible 7204.3443 (12045.81 seconds) Cbc0010I After 10600 nodes, 5406 on tree, 7965.8969 best solution, best possible 7204.3443 (12101.72 seconds) Cbc0010I After 10700 nodes, 5407 on tree, 7965.8969 best solution, best possible 7204.3443 (12146.58 seconds) Cbc0010I After 10800 nodes, 5415 on tree, 7965.8969 best solution, best possible 7204.3443 (12194.76 seconds) Cbc0010I After 10900 nodes, 5426 on tree, 7965.8969 best solution, best possible 7204.3443 (12241.25 seconds) Cbc0010I After 11000 nodes, 5403 on tree, 7965.8969 best solution, best possible 7204.3443 (12279.72 seconds) Cbc0010I After 11100 nodes, 5450 on tree, 7965.8969 best solution, best possible 7230.1812 (12454.36 seconds) Cbc0010I After 11200 nodes, 5500 on tree, 7965.8969 best solution, best possible 7236.2004 (12592.31 seconds) Cbc0010I After 11300 nodes, 5550 on tree, 7965.8969 best solution, best possible 7241.7213 (12727.55 seconds) Cbc0010I After 11400 nodes, 5599 on tree, 7965.8969 best solution, best possible 7244.9717 (12860.93 seconds) Cbc0038I Full problem 6935 rows 20001 columns, reduced to 1495 rows 1397 columns Cbc0010I After 11500 nodes, 5649 on tree, 7965.8969 best solution, best possible 7247.5071 (13033.07 seconds) Cbc0010I After 11600 nodes, 5699 on tree, 7965.8969 best solution, best possible 7250.5374 (13168.07 seconds) Cbc0010I After 11700 nodes, 5749 on tree, 7965.8969 best solution, best possible 7252.7822 (13301.78 seconds) Cbc0010I After 11800 nodes, 5799 on tree, 7965.8969 best solution, best possible 7254.6716 (13435.23 seconds) Cbc0010I After 11900 nodes, 5849 on tree, 7965.8969 best solution, best possible 7256.0169 (13564.35 seconds) Cbc0010I After 12000 nodes, 5899 on tree, 7965.8969 best solution, best possible 7257.3834 (13691.53 seconds) Cbc0010I After 12100 nodes, 5949 on tree, 7965.8969 best solution, best possible 7258.523 (13810.80 seconds) Cbc0010I After 12200 nodes, 5999 on tree, 7965.8969 best solution, best possible 7259.228 (13943.81 seconds) Cbc0010I After 12300 nodes, 6048 on tree, 7965.8969 best solution, best possible 7259.984 (14074.56 seconds) Cbc0010I After 12400 nodes, 6098 on tree, 7965.8969 best solution, best possible 7260.8806 (14209.42 seconds) Cbc0010I After 12500 nodes, 6148 on tree, 7965.8969 best solution, best possible 7261.5697 (14339.12 seconds) Cbc0010I After 12600 nodes, 6197 on tree, 7965.8969 best solution, best possible 7262.3536 (14462.38 seconds) Cbc0010I After 12700 nodes, 6247 on tree, 7965.8969 best solution, best possible 7263.0306 (14588.10 seconds) Cbc0010I After 12800 nodes, 6297 on tree, 7965.8969 best solution, best possible 7264.0462 (14714.12 seconds) Cbc0010I After 12900 nodes, 6347 on tree, 7965.8969 best solution, best possible 7265.0713 (14842.57 seconds) Cbc0010I After 13000 nodes, 6397 on tree, 7965.8969 best solution, best possible 7265.6957 (14963.84 seconds) Cbc0010I After 13100 nodes, 6497 on tree, 7965.8969 best solution, best possible 7265.6957 (15083.44 seconds) Cbc0010I After 13200 nodes, 6597 on tree, 7965.8969 best solution, best possible 7265.6957 (15180.30 seconds) Cbc0010I After 13300 nodes, 6673 on tree, 7965.8969 best solution, best possible 7265.6957 (15266.63 seconds) Cbc0010I After 13400 nodes, 6657 on tree, 7965.8969 best solution, best possible 7265.6957 (15366.70 seconds) Cbc0010I After 13500 nodes, 6678 on tree, 7965.8969 best solution, best possible 7265.6957 (15466.14 seconds) Cbc0010I After 13600 nodes, 6674 on tree, 7965.8969 best solution, best possible 7265.6957 (15587.53 seconds) Cbc0010I After 13700 nodes, 6674 on tree, 7965.8969 best solution, best possible 7265.6957 (15679.95 seconds) Cbc0010I After 13800 nodes, 6672 on tree, 7965.8969 best solution, best possible 7265.6957 (15779.99 seconds) Cbc0010I After 13900 nodes, 6680 on tree, 7965.8969 best solution, best possible 7265.6957 (15878.85 seconds) Cbc0010I After 14000 nodes, 6676 on tree, 7965.8969 best solution, best possible 7265.6957 (16007.21 seconds) Cbc0010I After 14100 nodes, 6726 on tree, 7965.8969 best solution, best possible 7266.3003 (16140.18 seconds) Cbc0010I After 14200 nodes, 6776 on tree, 7965.8969 best solution, best possible 7266.8724 (16270.12 seconds) WARNING: MustEliminateAfter? date is in possible stabling range. Warning: Period of interest starts before first rotation of producer 10. Warning: Period of interest starts before first rotation of producer 89. Warning: Period of interest starts before first rotation of producer 130. Traceback (most recent call last): File "/usr/local/bin/egg_solve", line 268, inmain(sys.argv[1:]) File "/usr/local/bin/egg_solve", line 190, in main sched = solver_func(prob, opt_tlim, opt_mipgap, sched, opt_threads) File "/usr/local/lib/python2.7/dist-packages/eggprob/solver/plpsolve.py", line 157, in plpsolve status = plp_prob.solve(plp.COIN_CMD(path="cbc", maxSeconds=tlimit, threads=threads, msg=1, fracGap=mipgap)) File "/usr/local/lib/python2.7/dist-packages/PuLP-1.5.4-py2.7.egg/pulp/pulp.py", line 1614, in solve status = solver.actualSolve(self, kwargs) File "/usr/local/lib/python2.7/dist-packages/PuLP-1.5.4-py2.7.egg/pulp/solvers.py", line 1276, in actualSolve return self.solve_CBC(lp, kwargs) File "/usr/local/lib/python2.7/dist-packages/PuLP-1.5.4-py2.7.egg/pulp/solvers.py", line 1338, in solve_CBC self.path pulp.solvers.PulpSolverError?: Pulp: Error while trying to execute cbc

and it runs on a debian7 machine.

Make seconds parameter work on Wallclock

When using the command line solver on Windows (cbc.exe) with multiple threads, the -seconds parameter which sets the time limit gets applied to the CPU seconds. On single thread CPU seconds equals Wallclock seconds.

It may be more usable when the seconds parameter sets the time limit for Wallclock seconds. The time used for the optimization may require more accurate steering, instead of the resource time.

With -seconds 7200 on single thread cbc.exe runs for almost 2 hours:

Total time (CPU seconds): 7175.61 (Wallclock seconds): 7175.61

With -threads 4 -seconds 7200 it stops after 36 minutes:

Total time (CPU seconds): 7166.48 (Wallclock seconds): 2170.56

[Trac #145] Infeasibility issue in MIP model built using flopCpp

image

Attachment(s): https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-145.zip

Hi,

I am solving an assignment and scheduling problem which is MIP and calling OsiCbcSolverInterface? from flopCpp to solve it. The solver is throwing that 'The LP relaxation is infeasible and too expensive'. I like to know if there is any functionality in COIN cbc library to check which constraint or group of constraints are causing infeasibility and also how to deal with these infeasibility issues in COIN environment. I know this functinality is available in CPLEX where CPLEX allows users to remove IISs(Irreducible Infeasibility Sets) but could not find it in COIN. May be I am completely unaware that this functionality does exist in COIN but I am unable to locate it. So please help to resolve this.

Thanks, Rakesh

[Trac #175] Is it free for commercial usage?

image

As you know, Open Solver uses CBC for solving the mathematical model. Can I use COIN-OR CBC (Linear solver) for commercial usage?

I will appreciate your help with this situation.

Best regards,

Configuration fails due to missing dependencies

It is nice to see Cbc repository finally mirrored on GitHub. However, building it fails at configuration step due to missing dependencies:

$./configure
...
checking for COIN-OR package CoinDepend... not given: No package 'cgl' found
No package 'osi' found
No package 'coinutils' found
configure: error: One or more required packages CoinUtils, Osi, and Cgl are not available.
configure: error: /bin/bash './configure' failed for Cbc

INSTALL readme contains incorrect information

In the INSTALL file the option of fetching the code form github its detailed, however the second part about fetching the dependecies does not work. Git returns this when I try:

fatal: repository 'https://github.com/coin-or/BuildTools/' not found

Below the part of the INSTALL document I am referring to:

   download stable version 2.9, as an example, you would execute
   the command

   git clone --branch=stable/2.9 https://github.com/coin-or/Cbc Cbc-2.9

   With git, you additionally, need to fetch the dependencies. To do so,
   execute

   cd Cbc-2.9
   git clone --branch=stable/0.8 https://github.com/coin-or/BuildTools
   BuildTools/get.dependencies fetch

I managed to install Cbc (including its dependencies) using the tarball from http://www.coin-or.org/download/source/Cbc.

[Trac #148] Standalone solver option nodeStrategy broken for up/down selection

image

Some of the values for this option are updepth, downdepth, upfewest, downfewest.

The code to distinguish the up/down direction seems to depend on the parity of the integer representing the option value, but this is the code:

int way = (((nodeStrategy - 1) % 1) == 1) ? -1 : +1; babModel_->setPreferredWay(way);

It seems that this should instead be:

int way = (((nodeStrategy - 1) % 2) == 1) ? -1 : +1; babModel_->setPreferredWay(way);

[Trac #149] CBC reports incorrect optimal objective value

image

Attachments: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-149.zip

CBC reports an incorrect optimal objective value when solving a trivial problem available in .nl format here: ​https://drive.google.com/file/d/0B8fdrkFjzN7mV2ZIODc5cnBIMm8/edit?usp=sharing

Running

cbc test.nl -AMPL

produces a file test.sol containing the line:

CBC 2.8.8 optimal, objective 4e+01

Apart from strange formatting (the optimal value it tries to report is actually 45), the value is incorrect as can be checked with any other solver, e.g.

cplex test.nl CPLEX 12.6.0.0: optimal solution; objective 15005 4 dual simplex iterations (3 in phase I)

One obvious issue is that the constant offset is not taken into account here: ​https://projects.coin-or.org/Cbc/browser/trunk/Cbc/src/CbcSolver.cpp?rev=1780#L2802

However, even when taking the offset into account, one can still see that the value returned from CoinModel::getObjValue is wrong.

[Trac #185] Preprocessing Error with CBC in pyomo

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-185.zip

Hi

I am solving a integer programming problem with CBC using pyomo in python.
When i am not specifying Preprocessing= "off" in model. CBC is giving following output.

Cbc0004I Integer solution of -18673.699 found after 106285 iterations and 5977 nodes (26.18 seconds)
Cbc0010I After 6000 nodes, 172 on tree, -18673.699 best solution, best possible -19341.306 (26.40 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 98 rows 123 columns
Cbc0010I After 7000 nodes, 606 on tree, -18673.699 best solution, best possible -19341.306 (30.37 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 97 rows 122 columns
Cbc0038I Full problem 487 rows 665 columns, reduced to 97 rows 122 columns
Cbc0010I After 8000 nodes, 1036 on tree, -18673.699 best solution, best possible -19341.306 (33.06 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 99 rows 124 columns
Cbc0012I Integer solution of -19005.863 found by rounding after 135072 iterations and 8417 nodes (34.26 seconds)
Cbc0012I Integer solution of -19165.821 found by rounding after 135100 iterations and 8424 nodes (34.28 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 66 rows 90 columns
Cbc0010I After 9000 nodes, 437 on tree, -19165.821 best solution, best possible -19341.306 (37.47 seconds)
Cbc0010I After 10000 nodes, 501 on tree, -19165.821 best solution, best possible -19341.306 (40.19 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 61 rows 83 columns
Cbc0010I After 11000 nodes, 522 on tree, -19165.821 best solution, best possible -19341.306 (42.42 seconds)
Cbc0010I After 12000 nodes, 878 on tree, -19165.821 best solution, best possible -19248.291 (56.64 seconds)
Cbc0010I After 13000 nodes, 1118 on tree, -19165.821 best solution, best possible -19232.913 (66.89 seconds)
Cbc0004I Integer solution of -19176.303 found after 304826 iterations and 13286 nodes (67.40 seconds)
Cbc0004I Integer solution of -19201.71 found after 309361 iterations and 13492 nodes (68.12 seconds)
Cbc0010I After 14000 nodes, 571 on tree, -19201.71 best solution, best possible -19232.913 (69.75 seconds)
Cbc0038I Full problem 487 rows 665 columns, reduced to 99 rows 136 columns
Cbc0010I After 15000 nodes, 577 on tree, -19201.71 best solution, best possible -19219.817 (79.08 seconds)
Cbc0011I Exiting as integer gap of 18.106987 less than 1e-10 or 0.1%
Cbc0001I Search completed - best objective -19201.70987434507, took 378930 iterations and 15001 nodes (79.10 seconds)
Cbc0032I Strong branching done 19396 times (255204 iterations), fathomed 333 nodes and fixed 2694 variables
Cbc0035I Maximum depth 151, 35742 variables fixed on reduced cost
0  Obj -21105.956 Primal inf 4822.701 (250) Dual inf 9.2984993e+13 (172)
End of values pass after 86 iterations
86  Obj -19926.913 Primal inf 455.19681 (89) Dual inf 5.1983959e+13 (105)
Perturbing problem by 0.001 % of 108.83248 - largest nonzero change 0.00080540261 (% 0.00085681129) - largest zero change 1.9933183e-05
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
167  Obj -19201.71 Primal inf 8.1575092e-07 (1)
Primal infeasible - objective value -19201.71
Cuts at root node changed objective from -22813.4 to -19341.3
Probing was tried 16542 times and created 78915 cuts of which 109 were active after adding rounds of cuts (4.173 seconds)
Gomory was tried 15528 times and created 31132 cuts of which 0 were active after adding rounds of cuts (5.924 seconds)
Knapsack was tried 15529 times and created 16043 cuts of which 0 were active after adding rounds of cuts (9.498 seconds)
Clique was tried 15 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.001 seconds)
MixedIntegerRounding2 was tried 15529 times and created 19002 cuts of which 0 were active after adding rounds of cuts (4.872 seconds)
FlowCover was tried 15 times and created 39 cuts of which 0 were active after adding rounds of cuts (0.008 seconds)
TwoMirCuts was tried 15528 times and created 6703 cuts of which 0 were active after adding rounds of cuts (2.403 seconds)
ImplicationCuts was tried 501 times and created 6044 cuts of which 0 were active after adding rounds of cuts (0.034 seconds)
Cgl0014I Postprocessing changed objective from -19201.71 to 0 - possible tolerance issue - try without preprocessing

Result - Optimal solution found (within gap tolerance)

Objective value:                -19201.70987435
Lower bound:                    -19219.817
Gap:                            0.00
Enumerated nodes:               15001
Total iterations:               378930
Time (CPU seconds):             78.91
Time (Wallclock seconds):       79.12

Total time (CPU seconds):       78.97   (Wallclock seconds):       79.18

But when i am specifying, Preprocessing = "off" in model, getting following output.

Cbc0010I After 1400 nodes, 501 on tree, -17956.092 best solution, best possible -19454.06 (57.00 seconds)
Cbc0038I Full problem 10441 rows 10504 columns, reduced to 49 rows 72 columns
Cbc0012I Integer solution of -18008.126 found by RINS after 42458 iterations and 1500 nodes (62.35 seconds)
Cbc0010I After 1500 nodes, 544 on tree, -18008.126 best solution, best possible -19454.06 (62.35 seconds)
Cbc0010I After 1600 nodes, 595 on tree, -18008.126 best solution, best possible -19454.06 (67.16 seconds)
Cbc0010I After 1700 nodes, 645 on tree, -18008.126 best solution, best possible -19454.06 (71.17 seconds)
Cbc0038I Full problem 10441 rows 10504 columns, reduced to 44 rows 71 columns
Cbc0012I Integer solution of -18277.113 found by RINS after 52959 iterations and 1800 nodes (75.27 seconds)
Cbc0010I After 1800 nodes, 634 on tree, -18277.113 best solution, best possible -19454.06 (75.27 seconds)
Cbc0010I After 1900 nodes, 679 on tree, -18277.113 best solution, best possible -19454.06 (80.47 seconds)
Cbc0010I After 2000 nodes, 727 on tree, -18277.113 best solution, best possible -19454.06 (84.79 seconds)
Cbc0010I After 2100 nodes, 777 on tree, -18277.113 best solution, best possible -19454.06 (89.12 seconds)
Cbc0010I After 2200 nodes, 820 on tree, -18277.113 best solution, best possible -19454.06 (93.46 seconds)
Cbc0010I After 2300 nodes, 863 on tree, -18277.113 best solution, best possible -19454.06 (97.97 seconds)
Cbc0038I Full problem 10441 rows 10504 columns, reduced to 42 rows 63 columns
Cbc0010I After 2400 nodes, 908 on tree, -18277.113 best solution, best possible -19454.06 (102.29 seconds)
Cbc0010I After 2500 nodes, 957 on tree, -18277.113 best solution, best possible -19454.06 (106.65 seconds)
Cbc0010I After 2600 nodes, 1005 on tree, -18277.113 best solution, best possible -19454.06 (111.13 seconds)
Cbc0010I After 2700 nodes, 1051 on tree, -18277.113 best solution, best possible -19454.06 (115.26 seconds)
Cbc0010I After 2800 nodes, 1099 on tree, -18277.113 best solution, best possible -19454.06 (119.16 seconds)
Cbc0020I Exiting on maximum time
Cbc0005I Partial search - best objective -18277.113 (best possible -19454.06), took 97910 iterations and 2822 nodes (120.03 seconds)
Cbc0032I Strong branching done 11466 times (68270 iterations), fathomed 17 nodes and fixed 157 variables
Cbc0035I Maximum depth 147, 2435 variables fixed on reduced cost
Cuts at root node changed objective from -25143.8 to -19454.1
Probing was tried 5616 times and created 41164 cuts of which 31 were active after adding rounds of cuts (6.332 seconds)
Gomory was tried 5611 times and created 12474 cuts of which 0 were active after adding rounds of cuts (14.109 seconds)
Knapsack was tried 5611 times and created 2807 cuts of which 0 were active after adding rounds of cuts (36.735 seconds)
Clique was tried 20 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.003 seconds)
MixedIntegerRounding2 was tried 5611 times and created 9514 cuts of which 0 were active after adding rounds of cuts (8.361 seconds)
FlowCover was tried 5611 times and created 988 cuts of which 0 were active after adding rounds of cuts (1.096 seconds)
TwoMirCuts was tried 5611 times and created 1985 cuts of which 0 were active after adding rounds of cuts (10.246 seconds)
ImplicationCuts was tried 34 times and created 198 cuts of which 0 were active after adding rounds of cuts (0.003 seconds)

Result - Stopped on time limit

Objective value:                -18277.11318678
Lower bound:                    -19454.060
Gap:                            0.06
Enumerated nodes:               2822
Total iterations:               97910
Time (CPU seconds):             119.41
Time (Wallclock seconds):       120.04

Total time (CPU seconds):       119.47   (Wallclock seconds):       120.10

The main problem is why do we need to specify preprocessing = "off" to get solution?
and when preprocessing is on, why it is converting optimal solution (objective) to 0.

Cgl0014I Postprocessing changed objective from -19201.71 to 0 - possible tolerance issue - try without preprocessing

I am also attaching LP problem file for your reference.

[Trac #184] cannot 'kill' randomness

image

When using mzn-cbc, even when passing 'randomCbcSeed 1' randomness is still there. The documentation says to 'set randomSeed for Clp' but it does not say how can this be done from the command line.

[Trac #166] Random CBC 2.9.6 crashes

image

Attachment(s): https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-166.zip

Hello,

I'm experiencing random crashes with CBC 2.9.6. The problem is difficult to reproduce. Most of the times by running the same model many times it crashes just once. Looks like an uninitialized variable or something like that.

I already tried on different computers, with different operating systems (Win XP, Windows Server 2012, Linux) with CBC built with different compilers (mingw32 with gcc 4.8.1, mingw64 with gcc 4.9.2, an old Linux server with gcc 4.4.4).

I have been able to get a reproducible crash only under Linux, but if I recompile CBC with debug symbols enabled it doesn't crash anymore. So I'm able to provide only a call stack of the crash, no detailed informations, I hope it's enough.

I attach the model used to get the crash, an execution log and the call stack provided by gdb. Let me know if there's something more I could do.

Thanks in advance for any help.

Bye,

=================

Hello,

this is just to let you know that the crash still happens with 2.9.7. I'm trying again to get a reproducible crash and see if the problem is still the same or if it is something different now.

Bye,

[Trac #186] Feasible problem reported as infeasible

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-186.zip

Hello,

the attached problem is reported as infeasible by CBC 2.9.9, even though it is feasible. Command line used is simply:

cbc -import inf.lp -solve -quit

If I set the ratiogap to an high value, say 0.5, a (suboptimal) feasible solution is found.

CBC has been compiled with mingw32 but I tested also with the supplied MSVC precompiled binaries to be sure it isn't just some compilation issue.

Hope it helps, and thanks for this excellent software.

Bye,

Denis Sbragion

[Trac #174] INSTALL readme contains incorrect information

image

In the INSTALL file the option of fetching the code form github its detailed, however the second part about fetching the dependecies does not work. Git returns this when I try:

fatal: repository 'https://github.com/coin-or/BuildTools/' not found

Below the part of the INSTALL document I am referring to:

   download stable version 2.9, as an example, you would execute
   the command

   git clone --branch=stable/2.9 https://github.com/coin-or/Cbc Cbc-2.9

   With git, you additionally, need to fetch the dependencies. To do so,
   execute

   cd Cbc-2.9
   git clone --branch=stable/0.8 https://github.com/coin-or/BuildTools
   BuildTools/get.dependencies fetch

I managed to install Cbc (including its dependencies) using the tarball from ​http://www.coin-or.org/download/source/Cbc.

NOTE: This ticket is a duplicate of a ticket on github ​coin-or/Cbc#8

Citing CBC in the scientific literature

Hi,

I am currently writing a scientific paper describing work I have done which relied on CBC as my ILP solver.
I was wondering what was the best way to credit CBC.
I've unsuccessfully looked for citing instructions on the FAQ and README.

If no "reference" paper has been published, have you considered using Zenodo? It's a free service allowing you to get a DOI for each release, that can then be cited; and is very easy to set up.

Thanks a lot for your time,
Bertrand

[Trac #173] undefine functions

image

hi i installed cbc and i tried to compile the example, and this show, the comand is:

make sample1

g++ -O3 -pipe -DNDEBUG -pedantic-errors -Wparentheses -Wreturn-type -Wcast-qual -Wall -Wpointer-arith -Wwrite-strings -Wconversion -Wno-unknown-pragmas -Wno-long-long -DCBC_BUILD -DSAMPLEDIR=\"PKG_CONFIG_PATH=/home/victorsalas/Descargas/Cbc-2.9/lib64/pkgconfig:/home/victorsalas/Descargas/Cbc-2.9/lib/pkgconfig:/home/victorsalas/Descargas/Cbc-2.9/share/pkgconfig: pkg-config --variable=datadir coindatasample\" -DMIPLIB3DIR=\"PKG_CONFIG_PATH=/home/victorsalas/Descargas/Cbc-2.9/lib64/pkgconfig:/home/victorsalas/Descargas/Cbc-2.9/lib/pkgconfig:/home/victorsalas/Descargas/Cbc-2.9/share/pkgconfig: pkg-config --variable=datadir coindatamiplib3\" sample1.cpp -o sample1 In file included from ../../build/include/coin/OsiSolverInterface.hpp:17:0,

from sample1.cpp:8:

../../build/include/coin/CoinFinite.hpp:20:14: warning: ‘COIN_INT_MAX_AS_DOUBLE’ defined but not used [-Wunused-variable]

const double COIN_INT_MAX_AS_DOUBLE = (std::numeric_limits<int>::max)();


/tmp/ccar1pzL.o: En la función `main': sample1.cpp:(.text.startup+0x61): referencia a `ClpSimplex::ClpSimplex?(bool)' sin definir

sample1.cpp:(.text.startup+0xa1): referencia a `ClpSimplex::readMps(char const*, bool, bool)' sin definir sample1.cpp:(.text.startup+0x170): referencia a `ClpPresolve::ClpPresolve?()' sin definir sample1.cpp:(.text.startup+0x19f): referencia a `ClpPresolve::presolvedModel(ClpSimplex?&, double, bool, int, bool, bool, char const*, char const*)' sin definir sample1.cpp:(.text.startup+0x248): referencia a `OsiClpSolverInterface::OsiClpSolverInterface?(ClpSimplex?*, bool)' sin definir sample1.cpp:(.text.startup+0x262): referencia a `OsiClpSolverInterface::writeMps(char const*, char const*, double) const' sin definir sample1.cpp:(.text.startup+0x26e): referencia a `OsiClpSolverInterface::initialSolve()' sin definir sample1.cpp:(.text.startup+0x30f): referencia a `CoinMessageHandler::setLogLevel(int)' sin definir sample1.cpp:(.text.startup+0x329): referencia a `CbcModel::CbcModel?(OsiSolverInterface? const&)' sin definir sample1.cpp:(.text.startup+0x335): referencia a `CbcCompareUser::CbcCompareUser?()' sin definir sample1.cpp:(.text.startup+0x348): referencia a `CbcModel::setNodeComparison(CbcCompareBase?&)' sin definir sample1.cpp:(.text.startup+0x354): referencia a `CglProbing::CglProbing?()' sin definir sample1.cpp:(.text.startup+0x365): referencia a `CglProbing::setUsingObjective(int)' sin definir sample1.cpp:(.text.startup+0x376): referencia a `CglProbing::setMaxPass(int)' sin definir sample1.cpp:(.text.startup+0x387): referencia a `CglProbing::setMaxProbe(int)' sin definir sample1.cpp:(.text.startup+0x398): referencia a `CglProbing::setMaxLook(int)' sin definir sample1.cpp:(.text.startup+0x3a9): referencia a `CglProbing::setRowCuts(int)' sin definir sample1.cpp:(.text.startup+0x3b7): referencia a `CbcModel::setNumberStrong(int)' sin definir sample1.cpp:(.text.startup+0x3fa): referencia a `CoinMessageHandler::setLogLevel(int)' sin definir sample1.cpp:(.text.startup+0x40f): referencia a `CoinMessageHandler::setLogLevel(int)' sin definir sample1.cpp:(.text.startup+0x41d): referencia a `CbcModel::branchAndBound(int)' sin definir sample1.cpp:(.text.startup+0x4c5): referencia a `typeinfo for OsiClpSolverInterface?' sin definir sample1.cpp:(.text.startup+0x4ca): referencia a `typeinfo for OsiSolverInterface?' sin definir sample1.cpp:(.text.startup+0x4d7): referencia a `OsiClpSolverInterface::getModelPtr() const' sin definir sample1.cpp:(.text.startup+0x4e2): referencia a `ClpSimplex::operator=(ClpSimplex? const&)' sin definir sample1.cpp:(.text.startup+0x4f3): referencia a `ClpPresolve::postsolve(bool)' sin definir sample1.cpp:(.text.startup+0x4ff): referencia a `ClpPresolve::originalColumns() const' sin definir sample1.cpp:(.text.startup+0x566): referencia a `ClpSimplex::primal(int, int)' sin definir sample1.cpp:(.text.startup+0x660): referencia a `CglProbing::~CglProbing?()' sin definir sample1.cpp:(.text.startup+0x66c): referencia a `CbcCompareUser::~CbcCompareUser?()' sin definir sample1.cpp:(.text.startup+0x678): referencia a `CbcModel::~CbcModel?()' sin definir sample1.cpp:(.text.startup+0x684): referencia a `OsiClpSolverInterface::~OsiClpSolverInterface?()' sin definir sample1.cpp:(.text.startup+0x690): referencia a `ClpPresolve::~ClpPresolve?()' sin definir sample1.cpp:(.text.startup+0x6b3): referencia a `ClpSimplex::~ClpSimplex?()' sin definir sample1.cpp:(.text.startup+0x6fd): referencia a `CoinMessageHandler::setLogLevel(int)' sin definir sample1.cpp:(.text.startup+0x70f): referencia a `CoinMessageHandler::setLogLevel(int)' sin definir sample1.cpp:(.text.startup+0x72f): referencia a `ClpPresolve::~ClpPresolve?()' sin definir sample1.cpp:(.text.startup+0x73b): referencia a `ClpSimplex::~ClpSimplex?()' sin definir sample1.cpp:(.text.startup+0x752): referencia a `OsiClpSolverInterface::~OsiClpSolverInterface?()' sin definir sample1.cpp:(.text.startup+0x768): referencia a `CglProbing::~CglProbing?()' sin definir sample1.cpp:(.text.startup+0x774): referencia a `CbcCompareUser::~CbcCompareUser?()' sin definir sample1.cpp:(.text.startup+0x780): referencia a `CbcModel::~CbcModel?()' sin definir collect2: error: ld returned 1 exit status <integrado>: fallo en las instrucciones para el objetivo 'sample1' make: * [sample1] Error 1

[Trac #161] Wrong optimum with files from MIPLIB2010

image

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

[Trac #164] Windows 10 and Visual Studio 2015

image

I have been using successfully CBC for many years. However, I tried to install version 2.9.5 using Windows 10 and Visual Studio 2015 unsuccessfully. There will be an update to include these new developments? Thank you.

===========
Comment from TKR: I just updated to Windows 10 and will try to have a look at it as time allows.

[Trac #181] NULL pointer dereference in

image

Attachment: https://github.com/s-c-e/cbc-trac-migration-attachments/blob/master/trac-ticket-181.zip

Hello.

I found a NULL pointer dereference in cbc.

Please confirm.

Thanks.

Summary: NULL pointer dereference

OS: CentOS 7 64bit

Version: Trunk (unstable)

Steps to reproduce:

1.Download the .POC files.

2.Compile the source code with ASan.

3.Execute the following command : ./cbc $POC

ASAN:DEADLYSIGNAL
=================================================================
==23114==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000018 (pc 0x000001697a01 bp 0x7ffe6bd33f10 sp 0x7ffe6bd33d40 T0)
==23114==The signal is caused by a READ memory access.
==23114==Hint: address points to the zero page.
    #0 0x1697a00 in CoinMpsCardReader::cleanCard() /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:280:19
    #1 0x16995b0 in CoinMpsCardReader::nextField() /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:516:10
    #2 0x16aab30 in CoinMpsIO::readMps(int&, CoinSet**&) /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:1633:18
    #3 0x16aa43f in CoinMpsIO::readMps(char const*, char const*, int&, CoinSet**&) /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:1573:10
    #4 0xc2a8db in OsiClpSolverInterface::readMps(char const*, bool, bool) /home/karas/Cbc/Clp/src/OsiClp/OsiClpSolverInterface.cpp:5765:24
    #5 0x561814 in CbcMain1(int, char const**, CbcModel&, int (*)(CbcModel*, int), CbcSolverUsefulData&) /home/karas/Cbc/Cbc/src/CbcSolver.cpp:7955:53
    #6 0x5254b6 in main /home/karas/Cbc/Cbc/src/CoinSolve.cpp:350:22
    #7 0x7fd8c61b21c0 in __libc_start_main /build/glibc-CxtIbX/glibc-2.26/csu/../csu/libc-start.c:308
    #8 0x42e049 in _start (/home/karas/Cbc/run/bin/cbc+0x42e049)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/karas/Cbc/CoinUtils/src/CoinMpsIO.cpp:280:19 in CoinMpsCardReader::cleanCard()
==23114==ABORTING

==========

[Acknowledgement]

This work was supported by ICT R&D program of MSIP/IITP. [R7518-16-1001,

Innovation hub for high Performance Computing]

[Trac #171] Crash in OsiClpSolverInterface::unmarkHotStart()

image

Hello,
I repeatedly get program crashes caused by OsiClpSolverInterface::unmarkHotStart(). The issue occurs "randomly" after many hours or days of calculation. I am using CBC 2.9.8. The error seems to occur only when using gcc/g++ 4.7 on Suse/Linux, but not when using Visual Studio 2013 (v120).

Stacktrace:

(gdb) bt 
#0  0x00007f17bdac46eb in raise () from /lib64/libpthread.so.0 
#1  0x00007f17bb692480 in skgesigOSCrash () from /opt/oracle/product/12.1/db_1/lib/libclntsh.so.12.1 
#2  0x00007f17bb95b9ee in kpeDbgSignalHandler () from /opt/oracle/product/12.1/db_1/lib/libclntsh.so.12.1 
#3  0x00007f17bb692660 in skgesig_sigactionHandler () from /opt/oracle/product/12.1/db_1/lib/libclntsh.so.12.1 
#4  <signal handler called> 
#5  0x00007f17bcd70b00 in OsiClpSolverInterface::unmarkHotStart() () from /home/k1471pn1/ext_comp/Cbc-2.9.8_gcc47_thread/lib/libOsiClp.so.1 
#6  0x00007f17bd8739a7 in CbcNode::chooseDynamicBranch(CbcModel*, CbcNode*, OsiSolverBranch*&, int) () from /home/k1471pn1/ext_comp/Cbc-2.9.8_gcc47_thread/lib/libCbc.so.3 
#7  0x00007f17bd8548c7 in CbcModel::chooseBranch(CbcNode*&, int, CbcNode*, OsiCuts&, bool&, CoinWarmStartBasis*, double const*, double const*, OsiSolverBranch*&) () 
   from /home/k1471pn1/ext_comp/Cbc-2.9.8_gcc47_thread/lib/libCbc.so.3 
#8  0x00007f17bd85c91d in CbcModel::doOneNode(CbcModel*, CbcNode*&, CbcNode*&) () from /home/k1471pn1/ext_comp/Cbc-2.9.8_gcc47_thread/lib/libCbc.so.3 
#9  0x00007f17bd8825c6 in doNodesThread(void*) () from /home/k1471pn1/ext_comp/Cbc-2.9.8_gcc47_thread/lib/libCbc.so.3 
#10 0x00007f17bdabc806 in start_thread () from /lib64/libpthread.so.0 
#11 0x00007f17b8bd164d in clone () from /lib64/libc.so.6 
#12 0x0000000000000000 in ?? () 

I assume there could be an issue with pointers that are deleted in unmarkHotStart() twice or were not initialilzed before deletion. Any suggestions how I could proceed in determining the source of the problem? Using log messages to narrow down the issue and causing an abortion on purpuse fail, because the log messages are not printed anymore (due to time delay for writting).

Thank you, David

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.