Next major release will be 10.0

[lperron]

Next major release should be 10.0.

We may have bug fix releases on the 9.9 branch.

The big change will be around linear and MIP solvers:

• MPSolver is deprecated. The code will be there for at least 1 full major release (so years).
• ModelBuilder (Python, Java, .NET) is already available.
  • This is for simple solve as there is no support for fast incremental solve (you can update the model, but the solver state is lost).
  • I have added support for indicator constraints.
  • C++ support is not planned.
• MathOpt will be launched.
  • It goals is to subsume MPSolver with more support for advanced techniques (i.e. incremental solve, branch and price, benders decomposition).
  • MathOpt will be available for Python and C++. Java will follow. C# will most likely never be implemented.
  • Currently MathOpt is already supported on the main branch with bazel. CMake support will be added for 10.0 and is being worked upon.
• For the solvers:
  • We would like to remove CLP/CBC from the default build, definitely CBC.
  • We plan to add Highs support for MathOpt.
  • SCIP is there, with the good license.
  • Gurobi is pre-loaded.
  • Our internal solvers (CP-SAT, GLOP, PDLP) are there.
  • We are working with RTE and the Fico team on supporting XPRESS-MP. RTE is working hard on the side-loading of the XPRESS-MP shared libraries (no need to recompile). This is done for MPSolver. It should be propagated to ModelBuilder. I do not know yet when it will be available for MathOpt.
  • We have just started talking with CardinalOpt. My goal is to have support with side-loading for ModelBuilder and MathOpt. 

For the rest of the tools:

• CP-SAT python has been rewritten for PEP8 (snake_case names) after the 9.8 release.
  • The previous CamelCase methods are still available.
  • I will provide a sed script to rename all methods.
• We are cleaning the graph API, removing the old code.   

The routing library will change.

• most of the routing code, headers will be moved to OR-Tools/routing
• the python layer will be completely rewritten to use pybind11.
• this will be a breaking change.

[jose-joaquim]

Hey @lperron, are there any specific reasons for why no C# wrapper for the MathOpt?

[lperron]

Because we do not use C# internally, the math_opt is very busy, and we do not have the resources to redevelop it. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le lun. 20 nov. 2023 à 16:18, José Joaquim de Andrade Neto < ***@***.***> a écrit :

…

Hey @lperron <https://github.com/lperron>, are there any specify reasons for why no C# wrapper for the MathOpt? — Reply to this email directly, view it on GitHub <#3992 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3NMPOJKQQXWF3YSTTTYFNYENAVCNFSM6AAAAAA7QZ4T5WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMMRQG42DK> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sgatto]

@lperron
We would like to contribute to make Xpress available for MathOpt. Is there anything in particular that you suggest we should start looking into?

[lperron]

Let's chat by mail.

[ktsteff]

Hi @lperron,

From what I can see

• ModelBuilder is now available for .NET and MPSolver is deprecated.
• ModelBuilder has no support for fast incremental solve (state is lost on update).
• MathOpt has support for fast incremental solve but will probably never be available for .Net

Does that mean there will probably never be support for fast incremental solve with OR Tools for .Net? Is there perhaps already a way/workaround to achieve it?

We have currently implemented column generation with OR Tools LinearSolver.Solver using "Clp". It seems to be slow for non-simple scenarios, which I guess makes sense if it starts over in each iteration after updating the restricted master problem.

Best,
Kasper

[lperron]

CLP implementation in OR-Tools MPSolver is not incremental.

[ktsteff]

Does that mean it will start from scratch whenever we call solve after having added variables in each iteration of CG?

Would it be different if we used any of the other solvers?

[lperron]

This is not the way to implement incrementality for a simplex. Store the basis status for variables and constraints, and set it back before solving.

This is implemented for glop, and not for CLP (the programming interface of CLP and CBC is unfriendly to say the least).

[ktsteff]

Thanks a lot @lperron, it's much appreciated. We will give Glop a try.

[ktsteff]

We have tried glop today and we can easily get the basis status. However, I'm in doubt about "set it back before solving". Wouldn't we need SetStartingLpBasis for that? I don't think that's available for .Net

[Diddlik]

Is there a reason why mpsolver is depricated?
We use it with GLOP (MPSolver::GLOP_LINEAR_PROGRAMMING) and there is currently no alternative.

[lperron]

As explained, we will have MathOpt (C++, Python) + ModelBuilder (Python, Java, C#) available. So there are alternatives. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le mer. 10 janv. 2024 à 14:25, Pavel ***@***.***> a écrit :

…

Is there a reason why mpsolver is depricated? We use it with GLOP (MPSolver::GLOP_LINEAR_PROGRAMMING) and there is currently no alternative. — Reply to this email directly, view it on GitHub <#3992 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3IAQX56C3VHZUMZOS3YN2JFLAVCNFSM6AAAAAA7QZ4T5WVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAOBQGA3TS> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pet-mit]

Hello! is Java support for MathOpt still on the roadmap?

[rma350]

Yes, although we are still iterating on the API a bit. There are also are some build related issues we need to sort out. I would hope this year some time, the sooner the better.

[svtuck]

Hi there, I was wondering if MathOpt in python is going to support quadratic constraints at launch - it looks like they are there in CPP.

[rma350]

No, the Python API is still a bit behind C++ unfortunately. For 2024 we are trying to do something a bit more systematic and support all features in Python.

[DenHvideDvaerg]

• MathOpt will be launched.

  • It goals is to subsume MPSolver with more support for advanced techniques (i.e. incremental solve, branch and price, benders decomposition).

Improved incremental solve sounds really good! How/where can I see which solvers will implement incremental solves? Actually, which solvers currently implement incremental solves? Does SCIP?

[rma350]

To check for incrementalism, look at a solver's implementation of math_opt::SolverInterface::Update(const ModelUpdateProto&)

https://github.com/google/or-tools/blob/stable/ortools/math_opt/core/solver_interface.h#L132

e.g. for SCIP:

https://github.com/google/or-tools/blob/stable/ortools/math_opt/solvers/gscip_solver.cc#L1175

So yes, SCIP is incremental (although for MIP, incrementalism adds less). Gurobi, GLOP, GLPK, and SCIP are largely incremental. PDLP, OSQP, and HiGHS are not, but these can all be improved to varying degrees (particularly HiGHS LP) with better code in MathOpt. CP-SAT does not support incrementalism in its MIP API.

[DenHvideDvaerg]

Thank you very much Ross!