Math-opt third-party solver support contribution: Early questions #4748
-
|
I'm considering adding CPLEX support to math-opt in or-tools (through PR). While i do understand the basic idea of the codebase and wrapping-approach, am familiar with c++, abseil and bazel (+ enough cmake), the questions is:
I don't intend to provide a PR supporting all kind of math-opt- or CPLEX-features in the first milestone, focusing on MILP and maybe Convex MIQP solving without any incrementality (aka "solving from scratch each time")!
As untested code is basically useless, there is a need for some thorough testing:
Without too much of an idea about C-API stability of evolving commercial solvers, it seems, that third-party solver wrappers are not partitioned into different solver-versions implying some kind of lock-step evolution with current versions.
In terms of learning and preparation:
Things to consider at a later point:
Currently i'm able to solve a simple MILP implying a basic setup of cplex_environment, cplex_solver and gcplex. But that's only a start of course. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
[A] I would try to follow the structure of gurobi/xpress. Write a minimal C++ wrapper of their a C API using absl primitives separately (and unit test this wrapper). We need to support loading cplex dynamically, just like the other solvers. Starting out with fewer features and building is in fact better than trying to do everything in one shot, it will make review much simpler. [B] There is no minimal feature set, you can get started with just LP if you want. There are solver independnent tests that are somewhat organized by supported features. You will make your life easier if you pick a set of features to support that is coherent with the tests (otherwise, you need to write solver specific tests, which is bad, or need to add more knobs on the tests to enable/disable things, which is also bad). Xpress in particular is community supported, I guess the contributor did not need MIP. Fixing this would be a welcome contribution. [C] The test suites under solver_tests are comprehensive (and include some easy miplib instances). I think we only guarantee supporting a single version of third party solvers at each version of or-tools, but I am not 100% sure how this works, you need to check with @lperron (somtimes I see ifdefs that are looking at the version, this is very hard for us to maintain). [D] Yes, I would guess that this is pretty stable now. [E] The cited changes/existing code is (unfortunately) the best reference. I would suggest breaking your work up into something that is both minimal and end to end at the same time (hard I know) and then trying to clean it up and send it for review, so you get feedback sooner. |
Beta Was this translation helpful? Give feedback.
[A] I would try to follow the structure of gurobi/xpress. Write a minimal C++ wrapper of their a C API using absl primitives separately (and unit test this wrapper). We need to support loading cplex dynamically, just like the other solvers. Starting out with fewer features and building is in fact better than trying to do everything in one shot, it will make review much simpler.
[B] There is no minimal feature set, you can get started with just LP if you want. There are solver independnent tests that are somewhat organized by supported features. You will make your life easier if you pick a set of features to support that is coherent with the tests (otherwise, you need to write solver speci…