SetNumThreads has no effect on Gurobi?

[gdowdy3]

What version of OR-Tools and what language are you using?
Version: v9.0.9048
Language: Python

Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi)
Gurobi

What operating system (Linux, Windows, ...) and version?
macOS Big Sur v11.6

What did you do?
Steps to reproduce the behavior:

1. Install ortools with pip3 install ortools
2. Install a Gurobi license.
3. Save the following script as MWE.py. This script is very similar to the example shown here: https://developers.google.com/optimization/lp/lp_example. However, there are a few changes:
   • Gurobi is specified as the solver.
   • The solver output is enabled.
   • The decision variables are integer-valued.
   • The number of threads is specified as 4.

from ortools.linear_solver import pywraplp


def LinearProgrammingExample():
    """Linear programming sample."""
    # Instantiate a Glop solver, naming it LinearExample.
    solver = pywraplp.Solver.CreateSolver('GUROBI')

    # Create the two variables and let them take on any non-negative value.
    x = solver.IntVar(0, solver.infinity(), 'x')
    y = solver.IntVar(0, solver.infinity(), 'y')

    print('Number of variables =', solver.NumVariables())

    # Constraint 0: x + 2y <= 14.
    solver.Add(x + 2 * y <= 14.0)

    # Constraint 1: 3x - y >= 0.
    solver.Add(3 * x - y >= 0.0)

    # Constraint 2: x - y <= 2.
    solver.Add(x - y <= 2.0)

    print('Number of constraints =', solver.NumConstraints())

    # Objective function: 3x + 4y.
    solver.Maximize(3 * x + 4 * y)

    # Set the number of threads
    solver.SetNumThreads(4)

    # Enable solver output
    solver.EnableOutput()

    # Solve the system.
    status = solver.Solve()

    if status == pywraplp.Solver.OPTIMAL:
        print('Solution:')
        print('Objective value =', solver.Objective().Value())
        print('x =', x.solution_value())
        print('y =', y.solution_value())
    else:
        print('The problem does not have an optimal solution.')

    print('\nAdvanced usage:')
    print('Problem solved in %f milliseconds' % solver.wall_time())
    print('Problem solved in %d iterations' % solver.iterations())


LinearProgrammingExample()

4. Run python3 MWE.py
5. Observe output.

What did you expect to see
Thread count: 8 physical cores, 16 logical processors, using up to 4 threads
Thread count was 4 (of 16 available processors)

What did you see instead?
Thread count: 8 physical cores, 16 logical processors, using up to 16 threads
Thread count was 16 (of 16 available processors)

Anything else we should know about your project / environment
When I was initially trying to set up ortools to use Gurobi on this machine, I had some trouble getting ortools to find Gurobi. In my efforts to solve the problem, I installed a fresh copy of Gurobi from https://www.gurobi.com. I also manually set up the GUROBI_HOME variable in my .zshenv. I believe this is the reason that I see the following whenever I run the above code.

I0430 18:18:55.265136     1 environment.cc:737] Found the Gurobi library in '/Library/gurobi912/mac64/lib/libgurobi91.dylib.

I'm not sure whether or not this is relevant.

[lperron]

Indeed. You should be able to work around by setting the solver specific parameter as string using the Gurobi names.

[gdowdy3]

Thanks for the quick reply!

Just to make sure I understand, is it the case that SetNumThreads has no effect on Gurobi by design? Or am I only experiencing this problem because I installed Gurobi myself?

[gdowdy3]

For the benefit of future generations, the work-around mentioned above is to replace

solver.SetNumThreads(4)

with

solver.SetSolverSpecificParametersAsString('Threads 4')

I have confirmed that this works. Thanks, @lperron!

[Mizux]

For the record: up to v9.1 gurobi_interface.cc doesn't implement SetNumThread() but have a flag

or-tools/ortools/linear_solver/gurobi_interface.cc

Lines 68 to 69 in 86d4c54

	ABSL_FLAG(int, num_gurobi_threads, 4,
	"Number of threads available for Gurobi.");

Which is only use at instantiation (in the ctor)

or-tools/ortools/linear_solver/gurobi_interface.cc

Lines 617 to 618 in 86d4c54

	CheckedGurobiCall(GRBsetintparam(env_, GRB_INT_PAR_THREADS,
	absl::GetFlag(FLAGS_num_gurobi_threads)));

While we should see (IMHO) something like in sat_interface.cc:

or-tools/ortools/linear_solver/sat_interface.cc

Line 99 in 86d4c54

absl::Status SetNumThreads(int num_threads) override;

or-tools/ortools/linear_solver/sat_interface.cc

Lines 294 to 297 in 86d4c54

	absl::Status SatInterface::SetNumThreads(int num_threads) {
	num_threads_ = num_threads;
	return absl::OkStatus();
	}

or-tools/ortools/linear_solver/sat_interface.cc

Line 106 in 86d4c54

int num_threads_ = 0;

or-tools/ortools/linear_solver/sat_interface.cc

Lines 287 to 288 in 86d4c54

	void SatInterface::SetParameters(const MPSolverParameters& param) {
	parameters_.set_num_search_workers(num_threads_);

and then setup during the solve() call

or-tools/ortools/linear_solver/sat_interface.cc

Lines 142 to 143 in 86d4c54

	request.set_solver_specific_parameters(
	EncodeSatParametersAsString(parameters_));