Is Parallel exploration of tree for MIP concurrent with callback execution?

Hello All,

I am preparing to use gurobi callbacks for the first time. (I have used cplex callbacks.)

I was hoping someone could answer the question below before I start.

I see the gurobi 9.0 python callback documentation says:

"When solving a model using multiple threads, the user callback is only ever called from a single thread, so you don't need to worry about the thread-safety of your callback"

Question:

With the following situation:

Solving a MIP model w/ multiple cores (say 24 cores), where model.optimize() was given my custom callback function which examines a new incumbent for feasibility ( given where = MIPSOL , 4, Found new MIP incumbent), and the callback adds a cut to eliminate the new candidate solution when not feasible.

Given that the process reaches the point of solving using all 24 cores (not in the root node, but deep in the branch and cut tree) will the other 23 cores continue to be used by gurobi to explore the branch and cut tree while my custom callback is executing on one core? Or will all gurobi threads stop while my callback is running?

Also, if multiple threads continue to explore the tree while one thread runs my callback, assuming any other candidate solutions that are found while my callback is running are queued by gurobi, when my callback completes, how is the next MIPSOL selected from the queue to be given to the callback? That is, are solutions to be given the callback selected from a FIFO queue? Or is it something like a priority queue (best objective value having the highest priority in the queue of candidate solutions to next be given to the callback) ?

Thank you, Lee

Matthias Miltenberger

Gurobi Staff

March 13, 2020 14:56

Hi Lee,

During a parallel optimization, all threads are communicating with each other. This includes new incumbents. They will all be reported to your callback.

While your callback is executed, the other threads are not going to continue exploring the tree. You can test this by adding a sleep() call in your callback.

The more threads you are using the more likely it is that new incumbents are found at the same time. This can also mean that one of those new solutions is not improving the current primal bound anymore. In such a case, you should not see this solution in your callback. You will also not see this solution reported in the log.

Does that answer your question?

Cheers,
Matthias

Lee Mitchell

March 13, 2020 17:24

Matthias, thank you for your reply. Yes you have answered my questions.

My hope was that Gurobi would continue to explore the tree while my callback is executed by one thread, but I understand this is not that case.

As a follow up question: Does your answer apply regardless of the programming language used, or is your answer specific to python ? (I am currently using python.)

Thanks again, Lee

March 16, 2020 07:53

Every interface is a wrapper of the C API, so this behavior is the same for all programming languages.

Is Parallel exploration of tree for MIP concurrent with callback execution?

Comments

Didn't find what you were looking for?