Math-Opt: Solver-oracle working in main process or not?

[sschnug]

Expectation

After watching the talk MathOpt: Solver Independent Modeling in Google's OR-Tools | Ross Anderson | JuliaCon 2023, most notably the visualization marked in the youtube-link i was under the impression, that the following happens during usage:

--------------
Parent process
--------------
// Build the model.
namespace math_opt = ::operations_research::math_opt;
math_opt::Model lp_model("getting_started_lp");
const math_opt::Variable x = lp_model.AddContinuousVariable(-1.0, 1.5, "x");
const math_opt::Variable y = lp_model.AddContinuousVariable(0.0, 1.0, "y");
lp_model.AddLinearConstraint(x + y <= 1.5, "c");
lp_model.Maximize(x + 2 * y);

// Solve and ensure an optimal solution was found with no errors.
const absl::StatusOr<math_opt::SolveResult> result =
    math_opt::Solve(lp_model, math_opt::SolverType::kGlop, args);
	
----------------------
Child process -> solve
----------------------

--------------
Parent process
--------------
CHECK_OK(result.status());
CHECK_OK(result->termination.EnsureIsOptimal());

meaning, that the chosen solver is working in it's own isolated process (process boundary in visualization). I think in some sense, the modelling-code is trusted (to not crash and so on), but the solver might not be.

Prelim analysis

I tried to skim over the math-opt code and it does not look like this is happening. Maybe i'm not seeing it, but i could not find anything which i would expect to see there (fork, exec, grpc-over-sockets...). I don't see any process-related shenanigans.

Question

• Am i wrong about my initial assumption that math-opt runs the chosen solver in it's own isolated process (with any IPC based on protobuf)?
• Will the implementation change in regards to this eventually?

---

Thanks!

And math-opt itself looks amazing!

[rma350]

In the open source build, you can currently only solve:

• In process
• Remotely on our machines by grpc/http and the OR-API: https://developers.google.com/optimization/service/math_opt/overview

For solving remotely, the only client library is in python, and it is not fully interoperable with a local solve (i.e. there is no common interface or enum to switch). You can use these tools from any language, but you need to build the http/grpc request yourself from the mathopt model.

We are working towards: gRPC client support in every language (for both the OR-API proto and the OR-Tools proto, not exactly the same), letting users run their own gRPC server, better abstractions to making local and remote solve interoperable, supporting the full callback API for remote solve, and subprocess solving. Many of these features work internally but have dependencies that do not work in open source.