The Cbc solver crashes Julia when using more than one threads for optimization. It gives an error message that Julia has exited. Here is a MWE based on JuMP tutorial on facility location:
using JuMP, Cbc, LinearAlgebra, Random
Random.seed!(314)
# number of clients
m = 12
# number of facility locations
n = 5
# Clients' locations
Xc = rand(m)
Yc = rand(m)
# Facilities' potential locations
Xf = rand(n)
Yf = rand(n)
# Fixed costs
f = ones(n);
# Distance
c = zeros(m, n)
for i in 1:m
for j in 1:n
c[i, j] = LinearAlgebra.norm([Xc[i] - Xf[j], Yc[i] - Yf[j]], 2)
end
end
ufl = Model(Cbc.Optimizer)
set_optimizer_attributes(ufl,"threads" => 8)
@variable(ufl, y[1:n], Bin);
@variable(ufl, x[1:m, 1:n], Bin);
@constraint(ufl, client_service[i in 1:m], sum(x[i, j] for j in 1:n) == 1);
@constraint(ufl, open_facility[i in 1:m, j in 1:n], x[i, j] <= y[j]);
@objective(ufl, Min, f'y + sum(c .* x));
optimize!(ufl)
println("Optimal value: ", objective_value(ufl))
I have following versions of the packges: Cbc v0.9.1, JuMP v0.22.1
Running on Windows 10, Julia 1.7.0, JuMP 0.22.1, Cbc 0.9.1
Welcome to the CBC MILP Solver
Version: 2.10.5
Build Date: Jan 1 1970
command line - Cbc_C_Interface -threads 8 -solve -quit (default strategy 1)
threads was changed from 0 to 8
Continuous objective value is 5.70184 - 0.00 seconds
Cgl0004I processed model has 72 rows, 65 columns (65 integer (65 of which binary)) and 180 elements
Cbc0038I Initial state - 0 integers unsatisfied sum - 0
Cbc0038I Solution found of 5.70184
Cbc0038I Before mini branch and bound, 65 integers at bound fixed and 0 continuous
Cbc0038I Mini branch and bound did not improve solution (0.02 seconds)
Cbc0038I After 0.02 seconds - Feasibility pump exiting with objective of 5.70184 - took 0.01 seconds
Cbc0012I Integer solution of 5.7018395 found by feasibility pump after 0 iterations and 0 nodes (0.03 seconds)
[process exited with code 3221225512]
Running without multi-threading.
i.e. commenting out set_optimizer_attributes(ufl,"threads" => 8)
Welcome to the CBC MILP Solver
Version: 2.10.5
Build Date: Jan 1 1970
command line - Cbc_C_Interface -solve -quit (default strategy 1)
Continuous objective value is 5.70184 - 0.00 seconds
Cgl0004I processed model has 72 rows, 65 columns (65 integer (65 of which binary)) and 180 elements
Cbc0038I Initial state - 0 integers unsatisfied sum - 0
Cbc0038I Solution found of 5.70184
Cbc0038I Before mini branch and bound, 65 integers at bound fixed and 0 continuous
Cbc0038I Mini branch and bound did not improve solution (0.03 seconds)
Cbc0038I After 0.03 seconds - Feasibility pump exiting with objective of 5.70184 - took 0.02 seconds
Cbc0012I Integer solution of 5.7018395 found by feasibility pump after 0 iterations and 0 nodes (0.04 seconds)
Cbc0001I Search completed - best objective 5.701839454572419, took 0 iterations and 0 nodes (0.04 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
Cuts at root node changed objective from 5.70184 to 5.70184
Probing was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Gomory was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Knapsack was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Clique was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
MixedIntegerRounding2 was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
FlowCover was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
TwoMirCuts was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
ZeroHalf was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Result - Optimal solution found
Objective value: 5.70183945
Enumerated nodes: 0
Total iterations: 0
Time (CPU seconds): 0.10
Time (Wallclock seconds): 0.10
Total time (CPU seconds): 0.12 (Wallclock seconds): 0.12
Optimal value: 5.701839454572419
I have tried setting threads to 2 but it also finds a solution and then exits the Julia session (see log below). Only setting number of threads to zero-the default in Cbc works.
I started Julia session using Juno and also tested in Julia command line.
I was not running multiple solves in parallel.
I don’t know whether the error with Cbc is windows specific or due to the Julia version (1.7 on the current system). I have used Cbc solver with multiple threads without issues in the past on a windows laptop with Julia version 1.6.
HiGHS works without issues. I used the option highs_min_threads to set the threads to 8.
Welcome to the CBC MILP Solver
Version: 2.10.5
Build Date: Jan 1 1970
command line - Cbc_C_Interface -threads 2 -solve -quit (default strategy 1)
threads was changed from 0 to 2
Continuous objective value is 5.70184 - 0.00 seconds
Cgl0004I processed model has 72 rows, 65 columns (65 integer (65 of which binary)) and 180 elements
Cbc0038I Initial state - 0 integers unsatisfied sum - 0
Cbc0038I Solution found of 5.70184
Cbc0038I Before mini branch and bound, 65 integers at bound fixed and 0 continuous
Cbc0038I Mini branch and bound did not improve solution (0.01 seconds)
Cbc0038I After 0.01 seconds - Feasibility pump exiting with objective of 5.70184 - took 0.00 seconds
Cbc0012I Integer solution of 5.7018395 found by feasibility pump after 0 iterations and 0 nodes (0.01 seconds)
Julia has exited.
Press Enter to start a new session.
I’ve also experienced this issue for the past year or so when upgrading to latest versions. I’ve been using older versions successfully. Julia 1.0.5; JuMP 0.20.0; Cbc 0.6.4. But when I’ve upgraded to later versions it just crashes. I also recently found that if I don’t see the threads parameter, then the problem seems to go away. I’m also using windows. It might be related to AMD vs Intel processor as well, but can’t confirm. I have a vague memory of a solve working on the Intel machine, but failing on the AMD machine; however, I no longer have access to both. And maybe I’m misremembering that.