Math-Opt: Solver-oracle working in main process or not? #4288
-
ExpectationAfter 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 analysisI 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
Thanks! And math-opt itself looks amazing! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
In the open source build, you can currently only solve:
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. |
Beta Was this translation helpful? Give feedback.
In the open source build, you can currently only solve:
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 …