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 have added Highs support for MathOpt.
  • SCIP is there, with the good license.
  • Gurobi is pre-loaded.
  • XPRESS is pre-loaded
  • Our internal solvers (CP-SAT, GLOP, PDLP) are there.
  • [no news] 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 has been moved to ortools/routing
• the python layer has been 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]

gurobi is optimized. This may be the only one.

[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.

[pet-mit]

Hi, any news on this?

[rma350]

No unfortunately. Java will not be in the 10.0 release, which is still in progress. We do not have a concrete plan for releasing the Java code we have yet.

[DenHvideDvaerg]

Any ETA on the 10.0 release? I'm hoping to use it for our next CMAKE-based project.

[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!

[lperron]

the plan is: - a 10.0.beta1 soon. It will include a namespace change for the routing library - stable math-opt python + c++ - partial rewrite of the routing python API to use pybind11 instead of SWIG. This will change the API. This rewrite will be complete for the 10.0 release. We will keep the old code (but with the namespace change) throughout the 10.x lifetime - tentative drop: GLPK, CLP, CBC, BOP - tentative change java from 1.8 to 21 - full support for XPRESS-MP I anticipate the beta to last 2-3 months as we rewrite the routing/constraint_solver python layer and iron out the bugs

[DenHvideDvaerg]

Thanks for the update Laurent!

[Mizux]

will add:

• Protobuf v33.0 for cmake (i.e. artifact), bazel is blocked to v32.0 (see Bazel: Protobuf v33 (python) requires @system_python protocolbuffers/protobuf#24084)
• SCIP v9.2.4 is out (https://github.com/scipopt/scip/releases/tag/v924)

[quentinplsrd]

Any update on version 10.0?
Or is the ortools project discontinued?

[Mizux]

still active, I try to keep the list of what remaining to publish our first 10.0 RC 1 here...
https://github.com/google/or-tools/issues?q=state%3Aopen%20milestone%3A%22v10.0.0%20RC1%22

[armeniomiranda-dev]

Hope to see it evolve for many years to come this project is awesome and powerful 🙏