Update an existing Optimization (missing inputplan)

[davidprem]

Hi,

let's say I want to pre-optimize a large amount of orders for the next day. Now during the night, some additional orders are being received through my order interface and I want to integrate those orders into the existing optimization really fast. Is there any way to do this or do I have to start from scratch with every received order?

Thank you!
David

[Bernd Welter]

Hi David,

first of all the API in the current status does not offer an input plan (as you are used to from the xTour service). But you could send the original orders plus the additional workload and plan from scratch. Probably the next step depends on the level of "fixation" you'd like to apply:
You can use constraints to keep existing assigments from the previous output, e.g.

• all orders which have been assigned to vehicle XY should remain attached to that vehicle (constraints-->combinations-->orderVehicle)
• all orders which have been assigned to be serviced from a specific depot should remain attached to that depot
• (update 8.11.2024): If the sequence is supposed to be kept, too: use categories such as "Seq[1]", "Seq[2]", "Sewq[3]"... and constraints.orders.respectedSequences "Seq[1] before"Seq[2]" ... to ensure that given sequences are kept. Attention: there might be limits in "how many constraints are allowed"...

It is more tricky if you want to keep assignment AND also sequences. I'll ask the competence center for some feedback about this approach.

Bernd

[TomDeDecker]

Hi David,

Indeed, as Bernd explained, we don't currently support the concept of further optimizing / expanding upon an existing planning. Each optimization request is considered as brand new problem for OptiFlow to tackle. This is contrary to our SaaS solution, which does offer support for such scenarios.

When sending a new request after the first run, you could include vehicle combination constraints and (if needed) respected sequences, to ensure some parts of your previous plan are re-used for the new planning. Fixing (part of) the routes will in many cases speed up the optimization, as there will be less options to explore for the engine, so you could reduce the optimization time for the second run in that case. Some small gains, at least.

Do note that in our experience, adding orders into a partially fixed planning, has real opportunity costs, compared to an optimization where the full order set is known from the start. Sometimes this opportunity cost outweighs the gains achieved from having a 2-step planning process, so it can be worth exploring whether the optimization could be scheduled after when the order set is (almost) fully identified.

Tom

[johantop]

Hello David,

The case you are explaining applies to an other customers on OptiFlow itself (independent of the Route Optimization OptiFlow API). Additionally, you have the option to use https://developer.conundra.eu/orderbook to consistently transmit your orders throughout the day and night. For those customers, we can initiate a scheduled plan, continuously incorporating updates to the orders, for example, during the night. This way, the customer has an optimized plan in the morning that has been consistently updated through that scheduling. Furthermore, the plan and the re-optimization do not start from scratch but build upon the previous optimization. Which contributes to improved optimization time for the entire process.

Note that this works only if the customer also manages their vehicles through the API of https://developer.conundra.eu/resource-management. Bernd is aware of this use case as well.

BR
Johan

[Bernd Welter]

Hi guys,

thanks for your answers - once again appreciated!

In this case we have to look close at the API version / process which a player is using.
As Tom mentioned: in PTV Developer Route Optimization OF there's no "memory" of previous output - each time an optimization is triggered the whole workload must be sent while PTV Orderbook API / PTV ResourceManagement API are designed to administrate object info in our backend and to refer to it multiple times if needed.

Please be aware of this conceptual difference,

Bernd

[Bernd Welter]

I am coming back to thus requirement as some more partners asked the same question.

What if the previously planned orders are given "no outsourcing costs" (not zero!) while the additional workload gets some ">0 outsourcing costs"

Does this ensure that the preplanned ones are kind of prio A?

[Bernd Welter]

Just received an update from our CPO An...

This topic is hot and in progress. We will dive deeper into the story soon and elaborate the usecase with you then.

[Bernd Welter]

important in this context: We now support input plans!

Check this article

And as first questions arised:

• You can fix orders to trips and so on just with the regular constraints...

Quite important in this context for users coming from xTour:

• xTour identifies which tours of an input plan are violated due to tour distance, working time, or whatever constraint. Such tours remain untouched, the violations are visible in the response. We only manipulate vehicles with no input tour and vehicles with valid tours (check this article) - these vehicles will get unviolated output tours.
• The Route Optimization OPTIFLOW API supports the use of input routes, allowing the algorithm to build on existing routes rather than starting from scratch. While the input routes serve as a starting point, the API does not guarantee that the planned orders will stay in their original positions; they are simply used as a foundation for optimization. If any constraints are violated within the input routes, the algorithm will adjust the plan by removing orders as needed to resolve the violations, ensuring that all constraints are met. The resulting optimized plan will never contain violations, even if the input routes initially had them.