ge0ffrey

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.

I beg to differ. Timefold is used daily in real-world operations.

Neither our clusters in the US or EU can afford to go down for a minute, or business operations in logistics, retail and healthcare are impacted.

> They do not adequately account for traffic, driver preferences, or other factors that require a continuous feedback

- Traffic: supported

- Driver preferences: the APIs support

-- Area affinity (soft) and geo fencing (hard)

-- Fairness and load balancing of work (soft)

-- Overtime (soft and hard)

-- Seniors not doing boring junior tasks (soft)

- Continuous feedback: the APIs support

-- Real-time rescheduling (warm starts) as actual execution data comes in.

-- Recommend assignment: scheduling in survival mode

-- Pinning: user stays in control through overriding assignments

-- Explainability: why a certain decision was made

-- Insights: what are the bottlenecks in my schedule - what type of employees should I hire or upskill.

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.

Ideally, the solver doesn't just run on the backend, it's also orchestrated to run a pod per solver, with scale to zero.

I wonder if the same can be done with Timefold's quickstarts https://github.com/TimefoldAI/timefold-quickstarts

Did you transpile OR tools's entire codebase from C++ to JavaScript with AI?

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.

For Job Shop Scheduling like this, Timefold has two implementations:

- Basic: an open source Food Packaging quickstart on solver.timefold.ai

- Advanced: a Job Scheduling REST API on app.timefold.ai

Other open source solvers:

- Timefold Solver (not MIP, focussed on vehicle routing, job scheduling, shift rostering, etc): http://solver.timefold.ai

- Several solvers at COIN-OR: https://www.coin-or.org/

- Choco

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

There is truth in this.

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?

Definitely! I'll let her know :)

Thank you!

Those examples are available in Java, Python and Kotlin.

We also have an overview of our open source solver here: https://timefold.ai/open-source-solver

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

Yes! These days, to handle cases with more work than resources to do it, medium constraints are used a lot too (so hard/medium/soft constaints), to penalize the amount of unassigned work. Those are harder than soft constraints, but softer than hard constraints.

Take a look at OSRM. For the Timefold Field Service Routing REST APIs, we have a maps service that runs OSRM under hood by default, but supports alternative map providers too. It calculates both travel time and distance matrixes.

Our maps service does do a bunch of additional optimizations (caching, incremental requests, ...) to assist any solver model we run that request maps information.

Thanks for sharing your story too, Yorak.

Yes, having in-house expertise to integration optimization into their existing tools is hard. Especially if they use low level solver APIs (especially if it's math equations).

We're working making that easier with high-level REST APIs (Timefold Field Service Routing, etc). And with education (Timefold Academy) by creating videos and articles on how to integrate real-time planning, continuous planning, labor law constraints, fairness, cost reduction, etc

See https://www.youtube.com/@timefold/videos

When you make the leap, you're basically living your savings.

Until the startup has investors that agree to pay the founders a wage (to reduce personal financial stress so they can concentrate on the company) - or the startup is profitable - it's vital that your savings don't run out...

I once wrote an open source factory design optimizer with Timefold (previously OptaPlanner). It figured out the best layout to produce a particular item, for example green vials.

We ended up removing it from the default quickstarts [1], but maybe we should reinstate it in timefold-sandbox?

[1] https://github.com/TimefoldAI/timefold-quickstarts/commit/d9...

Thanks Aeolun! We're going to improve the documentation further. I am going to take this feedback along.