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.

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.

Some our customers want to go even higher, and we're working on that.

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.

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.

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

Comments URL: https://news.ycombinator.com/item?id=47204663

Points: 5

# Comments: 0

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

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

- 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

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.

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.

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.

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 also have an overview of our open source solver here: https://timefold.ai/open-source-solver