We run the Mittelman VRPLib benchmarks at Timefold (and beat other open source solvers like or-tools in 95%+ of the X datasets).
But they are not representive of the real world, at all.
The Mittelman VRPLib benchmarks have only 1-2 constraints. Skills? No need. Working hours? Unlimited. Maps integretion? Cars can fly and the earth is a flat Euclidean space.
Any VRP algorithm optimized for the vrplib datasets is overfitted and not the best one in reality.
Take HGS for instance. Brilliant for CVRPTW. Crumbles to dust in field service routing for telco operations etc.
That being said:
I fully agree that the solver industry as a whole has focused for far too long on global optima for academic requirements, instead of real-world use for the actual business requirements, and how to deal with business objective changes each quarter.
Our version of a Solver as a Service deals with cases of up to 390'000 shifts in a single dataset for shift scheduling and 30'000 visits for vehicle routing problems.
Some our customers want to go even higher, and we're working on that.
There is an audience for such platforms - Timefold Platform optimizes 1,000,000 visits and 2,000,000 shifts per week - but only if it's more than just orchestration.
If it handles explainabily, what-if scenarios and insights to fulfill business needs.
And that's where supporting many solvers becomes the blocker.
A lowest common denominator design.
Those solvers are a black box. They don't expose what they're running, why they made certain decisions or how they can scale to large datasets or complex business requirements.
We've picked our poison: one solver, which we've built in the open, in the last 20 years, versatile enough to handle any scheduling problem. That delivers.
Sounds similar to Timefold Platform: app.timefold.ai
That's our Solver as a Service for scheduling problems (vehicle routing problem, shift scheduling, job scheduling, etc). It runs scheduling problems implemented with our open source solver: solver.timefold.ai
But this post is such a service for formula problems instead (think master capacity planning, portfolio optimization, etc), due to the choice of MILP solvers underneath. Similar to NextMv, Neos, etc.
Nonsense. Timefold Solver and other open source vehicle routing problem solvers deliver better results in less time, with affordable hardware, especially for real-world complexity.
I would argue that inputting a loadBalance(sum(shift.duration)) function per employee is a higher level abstraction than inputting a quadratic math equation to accomplish the same thing.
Think Java/C++/Python vs Assembly.
Ironically, talking about problem reduction... most math equation based solver can't scale quadratic equations, so users "relax" the business constraints (to the point that projects fail in production).
Without involving the human planners, the project won't succeed. We're empowering them, with PlanningAI assistance, so they can focus on what they planning must do, for who, instead of how it gets there. So when the plan goes off the rails - 5 people call in sick - they can get it back on the rails in seconds with Real-Time Planning.
The engineering work is only half the work, or less. Fitting the technology into the human processes is another big chunk. Half of my videos on youtube deal with such cases: Continuous Planning, Real-Time Planning, Non-distruptive Replanning, Pinning, ... Not code, not technology, but design patterns.
And even then, this is far from 100% of the solution. Technology and education is still not enough.
That human planner with 30 years of business knowledge in his/her head is still a critical: he/she will always need to tweak, oversee and sometimes overrule the planning solution in production.
A 10% productivity gain is a lot for any company, regardless if they are operating a fleet of 50 or 50 000 vehicles.
However, the cost and risk to achieve that productivity gain is typically huge. Many Operations Research projects fail. And when they do, they are very expensive failures. "Managers getting fired" expensive.
With our technology, we're making OR projects easy and quick to put into production.
The Project Job Scheduling example was terrible. We deleted it, and replaced it with the much cleaner Food Packaging quickstart.
Out of all our quickstarts, Project Job Scheduling is - by far - the one I am least proud of. It was overfitted for a particular problem and - in hindsight - it didn't align well to real-world variants of Job Shop Scheduling that many people face. But before Food Packaging, it was all we had.
Sorry for the pain. Thanks for sharing these insights.
Our goal is to make planning optimization easy. But planning optimization can be extremely complex. So it took us quite some time to make it easy. Timefold Solver is already a lot easier than OptaPlanner to use. And the Timefold REST APIs are even easier: if you have a vehicle routing or shift scheduling case on your hands, just send in your data and get the solution.
But not all cases are easy...
What kind of use case where you trying to solve with OptaPlanner? In the past, I've seen a strong correlation between the ease of solving the problem and the availability of of a quickstart example.
For example, our tech is even used for court scheduling (in different countries), but every single one of those cases was difficult. Other cases are far more simple.
It all depends on the planning problem.
Do you remember any particular pain in your OptaPlanner experience that we can improve going forward? Around which year was this?
We support Simulated Annealing too, as well as Tabu Search and many others. By default Timefold Solver uses Late Acceptance, which behaves like Simulated Annealing but isn't parameter tuning fickle like SA.
Do note that the base algorithm (such as SA, TS or LA) is less than 5% of the work to get great results. We do a lot of additional things on top of that (incremental score calculation, smart neighborhood selection, multi threaded solving and many more).