Additional solvers

[BastianZim]

or-tools supports a wide range of solvers, not all of which are included in the packages available through conda-forge.
if there is a solver you would like to see included, please either create a PR with the respective flags set or add a comment to this issue here.

Do note though that the solver will have to be available through conda-forge.

[Mizux]

@BastianZim please edit this comment and/or copy past it in your topic top message and suppress it ;)

Current list of supported solver through MPSolver

• Google BOP (can't be disable IIRC)
• COINOR Cbc (by default ON)
• COINOR Clp (by default ON)
• Google CP-SAT (can't be disable IIRC)
• CPLEX (compile time deps)
• Google GLOP (can't be disable IIRC)
• GLPK (by default OFF due to GPL license issue, don't know if conda package enable it)
• Gurobi (need license but is dynamicly loaded so can be enable "for free")
• Google Knapsack solver (can't be disable IIRC)
• Google PDLP (will be available in v9.3)
• SCIP
• XPRESS (compile time deps)

ref: https://github.com/google/or-tools/blob/2cb85b4eead4c38e1c54b48044f92087cf165bce/ortools/linear_solver/linear_solver.h#L191-L223

[Mizux]

GLPK could be enable IMHO, conda already package it...
note: Using a GLPK system-wide package install has not been (fully) tested IIRC so don't hesitate to ping me for support/patch if needed !
i.e. https://github.com/google/or-tools/blob/stable/cmake/FindGLPK.cmake may need improvement like pkgconfig search...

ref: https://github.com/conda-forge/glpk-feedstock

[Mizux]

FYI https://github.com/ERGO-Code/HiGHS is not yet supported by or-tools (google/or-tools#3116)

[BastianZim]

Thanks for the list @Mizux! To be honest, I had opened the issue because I wasn't sure if someone needs additional solvers and first wanted to check that but I guess it wouldn't be too bad to have them in the box from the beginning, especially when #7 is solved.

A couple of points:

1. The build instructions are in https://github.com/conda-forge/or-tools-feedstock/blob/master/recipe/build-python.sh (Just RE the solvers that are currently enabled)

2. One thing to think about is the licensing and packaging. If we include all of the solvers we'll soon run into a problem where some of the solvers might have more restrictive licensing than or-tools itself so they would have to be in a separate or-tools package, I would suggest. When Providing user's license choice conda-forge.github.io#1608 is merged this will be easier but until then I would first like to define a naming convention where we either include the solver name or some other defining feature in the name. What do you think?

3. Some time ago there was a discussion in or-tools about integrating solvers only when running the program and or-tools not necessarily being compiled against them. Do you know if there is any progress in that direction? I cannot remember the full issue but I can try to find it. I think it was similar to what you are doing with Gurobi.

[Mizux]

I would explicit list all solver (even ones ON/OFF by default) so you can see directly in build-python.sh the full setup.
i.e. to add:

 -DUSE_COINOR=ON
 -DUSE_GLPK=OFF
 -DUSE_CPLEX=OFF
 -DUSE_XPRESS=OFF

2. so wait and see...

3. TLDR: stall lacking of human ressource.
   I guess you mean Load-time dynamic linking of solver libraries causes problems google/or-tools#770
   pro: distro way to split a packages and have a runtime load for "optional" deps

cons: start to have compatibility issue if deps shipped by various distro is not up to date etc...
note: it's the job of distro maintainer to bump deps and deal with it BTW but I don't see how we could support multiple version of each or-tools deps without making a burn out ;)

cons: windows and shared lib load at runtime... -> need symbols exported etc.... which is usually never done for oss library since on unix by default everything not have the visibility=hidden nor deal with import/export
note: could be mitigate by having only windows platform NOT performing runtime load per default

cons: for language wrapper python, java, .net we want a standalone package if possible (aka too complicate for java user to understand distro package deps...)
note: which means here we may still want to have compile time deps
note: python also recommend to ship all your deps PEP 513

so I would say it doable, no ressource to work on it and I think we still want to have a compile time deps mode.
-> maybe control the behaviour by an option kind of option(USE_DYNAMIC_SCIP OFF) if off like before if on, use a gurobi like dynamic load of the deps...

[BastianZim]

1. Good idea. Once Rebuild for abseil_cpp20211102 #7 is passing (Do you by chance know why these errors occur?) I will rerun the PR to get a clean commit history and then add these parts as well.
2. 😄
3. Yes that was the one. Ok understood, I guess you could introduce a very strict pin so no compatibility issues would occur but that is probably quite restrictive as well. And yes PEP 513 is a concern for normal distribution but here the conda solver takes care of that so we actually prefer it the other way around so that we can supply our own packages. But I understand that we're very small compared to the whole or-tools ecosystem. Obviously I agree that having everything behind a switch would be the best but yes, probably too much work for an, in the end, very small problem. 😄

[h-vetinari]

I see scip mentioned here so maybe this is not worth a separate issue, but I'd like to remove the run_constrained: scip=7.0.1, or at least document what's necessary to remove it. The feedstock has moved on, and having such constraints makes environment resolution much harder (though that can be justified, it shouldn't persist indefinitely, as things become progressively less co-installable).

I've trawled the conversation in the original staged-recipes PR (well, unfolded the 180+ comments and searched for "scip"), but it's not clear to me where this comes from.

[BastianZim]

This came originally from upstream. The reason it wasn't included was because of its license.

@Mizux Sorry to be pinging you out of the blue. Do you know if you rely on a specific version of scip or can we remove this pin here?

[Mizux]

AFAIK we just pick the lastest release of SCIP when fetching deps but it should works with previous ones too since the scip_interface.cpp (i.e. scip API) didn't change...
ps: Please note last SCIP version (tag v801) is broken with python see google/or-tools#3454 (TLDR patch send as PR to SCIP on master they should backport it to their v80-fix "internal" branch asap)
pps: so you could apply patch https://github.com/google/or-tools/blob/main/patches/scip-v801.patch if conda wnat to use it ;)
ppps: scip PR: scipopt/scip#24

[h-vetinari]

AFAIK we just pick the lastest release of SCIP when fetching deps but it should works with previous ones too since the scip_interface.cpp (i.e. scip API) didn't change...

It's completely fine if there's a dependence on an exact version of scip, but what we should then do is make it part of the global pinning and recompile whatever depends on it, as soon as there's a new version.

The point I was getting at is that indefinite constraint to an old version is bound to lead to issues.

[BastianZim]

Thanks @Mizux! :)

The point I was getting at is that indefinite constraint to an old version is bound to lead to issues.

Agreed. I think, initially, we only pulled this forward when it changed upstream but this definitely makes more sense.