Add Parallel Bounds check

[jd-lara]

I made a quick test trying to parallelize the numerical bounds checking and it crashed Gurobi and Xpress when using direct_mode. I think we should integrate the JuMP library dependency and work on parallelizing this code because in large model where it can matter a lot, it is very expensive at the moment.

[odow]

Do you have a reproducible example? I don't think there's much we could do here. It first depends if the C API of the solver is thread-safe, and it also depends if the Julia solver wrapper is thread-safe. Neither of those things are easy to test.

[jd-lara]

@odow here is the commit that triggered the issue

Sienna-Platform/PowerSimulations.jl@68d8070

[odow]

Okay, I've been looking into this. There are two issues with threads. I'll comment about Gurobi, but it applies to other solvers as well (Xpress, HiGHS, etc).

Is the Julia wrapper thread safe?

The first question is whether the Julia wrappers are thread safe. In most cases, the current answer is "no". However, this is code that we control, so it's something we could work on fixing.

Here's an example from Gurobi:

https://github.com/jump-dev/Gurobi.jl/blob/2b36c30c75a20c8b46f68e77894bcda2f4973da6/src/MOI_wrapper/MOI_wrapper.jl#L2326-L2349

This code is not thread safe because the call _update_if_necessary(model) may modify internal state of the Gurobi.Optimizer object.

We could fix this by adding a lock to ensure that only one thread can update the model at a time. But we would need to go through each function in the wrapper. This is tedious and error-prone. It is particularly hard to test and debug thread safety issues. It's also brittle: we'd need to ensure that all future changes to the solver wrapper preserved thread safety.

Is the underlying solver thread safe?

Let's assume we have fixed all thread safety issues in the Julia code. Is the underlying solver thread safe?

Some operations are clearly not thread safe and can probably never be made so. Optimising the same model from two threads isn't. Modifying the model by adding or deleting constraints and variables isn't. Others are less obvious. Can I query the value of a RHS coefficient in parallel?

Unless explicitly documented by the solver, we must assume no. In Gurobi's case, their documentation explicitly says that models (and the underlying environment are not thread safe).

There could be multiple reasons for this:

1. there could be some global state in the model that caches results, or applies updates like we do in the Julia code linked above
2. there could be issues with concurrent accesses to the license validation mechanism in the GRBEnv. That seems pretty plausible because they don't like it when people try to use more cores than their license conditions etc.

Regardless, even if something works in all of the tests you run, there's no guarantee that it will work for everyone, every time, on every machine.

Alternatives

Querying functions and sets from a JuMP cache (that is, use model = Model(Gurobi.Optimizer) instead of model = direct_model(Gurobi.Optimizer()) should work.

If there are any issues, I'd be open to declaring that a bug we should fix.