We have the problem that CBC in SHOT sometimes writes to stdout instead of using the message handler passed to it. For example, on GAMS testlib model sosminlp01, for the first MINLP, one gets the following log (with dualsolver log enabled):
Solving dual problem.
| processed model has 0 rows, 4 columns (4 integer (0 of which binary)) and 0 elements
| At root node, 0 cuts changed objective from -20 to -20 in 1 passes
| Cut generator 0 (Probing) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.000 seconds - new frequency is -100
| Cut generator 1 (Gomory) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.000 seconds - new frequency is -100
| Cut generator 2 (Knapsack) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.000 seconds - new frequency is -100
| Cut generator 3 (Clique) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.000 seconds - new frequency is -100
| Cut generator 4 (MixedIntegerRounding2) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.000 seconds - new frequency is -100
| Cut generator 5 (FlowCover) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.000 seconds - new frequency is -100
| After 0 nodes, 1 on tree, 1e+50 best solution, best possible -20 (0.00 seconds)
Integer solution of -6 found by strong branching after 0 iterations and 1 nodes (0.00 seconds)
0 Obj -8
Integer solution of -8 found by strong branching after 0 iterations and 1 nodes (0.00 seconds)
| Integer solution of -8 found by heuristic after 0 iterations and 0 nodes (0.00 seconds)
| Thread 0 used 2 times, waiting to start 8.4400177e-05, 0.000184 cpu time, 10 locks, 4.4584274e-05 locked, 4.7683716e-07 waiting for locks
| Main thread 0.00022983551 waiting for threads, 8 locks, 2.8610229e-06 locked, 2.3841858e-07 waiting for locks
| Search completed - best objective -8, took 0 iterations and 2 nodes (0.00 seconds)
| Maximum depth 0, 0 variables fixed on reduced cost
The strong branching lines are printed to stdout.
It seems that this is related to multithreading in Cbc, because it goes away when not passing --threads 1 to Cbc.
So this MR changes SHOT to skip --threads 1 (or --threads 101). I am aware it is just a workaround. Maybe it also improves Cbc performance when run single-threaded.
We have the problem that CBC in SHOT sometimes writes to stdout instead of using the message handler passed to it. For example, on GAMS testlib model sosminlp01, for the first MINLP, one gets the following log (with dualsolver log enabled):
The
strong branchinglines are printed to stdout.It seems that this is related to multithreading in Cbc, because it goes away when not passing
--threads 1to Cbc.So this MR changes SHOT to skip
--threads 1(or--threads 101). I am aware it is just a workaround. Maybe it also improves Cbc performance when run single-threaded.