Return To Start (Return2Start) — Insert Mandatory Depot Returns Between Visits

Return To Start (often referred to as Return2Start) is a routing feature that forces a resource to return to its start location (home/depot) between visits.

In practical terms, the optimizer is allowed to build a route like:

• Visit Node A
• Return to Start (optional fixed dwell time)
• Visit Node B
• Return to Start (optional fixed dwell time)
• Visit Node C
• …

This is a highly effective architectural tool for problems where “direct chaining” between customer visits is not allowed or not realistic.

Primary reference: https://www.dna-evolutions.com/docs/learn-and-explore/feature-guides/return_to_start

References

• Documentation: https://www.dna-evolutions.com/docs/learn-and-explore/feature-guides/return_to_start
• Example source: ReturnStartExample.java

Typical use cases

Return2Start is commonly used when a resource must return to a base between tasks, for example:

• Reloading / restocking (goods, tools, spare parts)
• Pickup & Delivery simplification for “return after each delivery” patterns
• Regulated operations where vehicles must return to a controlled yard between jobs
• Medical or lab logistics with mandatory depot handling steps
• Quality / paperwork / scanning steps that must happen at the base
• Battery charging or equipment swap at the depot

In short: whenever your process requires an explicit depot loop that is not just “route termination”.

How it differs from “closed route”

These concepts are related but not the same:

Closed Route

A closed route means:

• the route ends by returning to the start location at the end of the route.

Return2Start

Return2Start means:

• the resource returns to the start location between visits, multiple times per route.

Important nuance (also stated in the documentation and source comments):

• returning home via Return2Start does not count as route termination.
  It is modeled as an intermediate return leg inserted between adjacent nodes.

In the example, routes are explicitly set to open:

• workingHours.stream().forEach(w -> w.setIsClosedRoute(false));

This makes the difference even clearer:

• even though the route is open (no final return required), Return2Start still inserts intermediate returns.

How to enable Return2Start

Return2Start is activated per node:

• node.setIsReturnStart(intermediateStayAtHomeDuration);

This tells the optimizer:

• before continuing from this node to the next node, return to the resource start location,
• stay there for the given duration,
• then proceed to the next visit.

The “stay at home” duration (intermediate depot dwell time)

In ReturnStartExample, this is configured once and applied to multiple nodes:

• Duration intermediateStayAtHomeDuration = Duration.ofMinutes(20);

Interpretation:

• after each affected visit, the resource must “spend” 20 minutes at the start location (e.g., reload, paperwork, handover, charging).

Why this matters:

• without the dwell time, Return2Start would represent “drive home and immediately leave again”.
• with dwell time, you get a more realistic model and better time-window feasibility behavior.

What happens in the solution (how to read the result)

When Return2Start is active, the solver inserts autogenerated intermediate nodes that represent:

• “Visited node → Resource start”
  plus the configured dwell time at the start location.

In the documentation’s sample output, this is visible as additional steps like:

• Wuppertal -> Jack from Aachen
• Essen -> Jack from Aachen
• Koeln -> Jack from Aachen

This is the key diagnostic signature:

• between adjacent customer nodes you will see an extra leg back to the resource start.

Operational interpretation:

• the route is still one route,
• but it contains explicit depot loops.

Why this can be better than modeling full PND (and when it is not)

The documentation lists a core advantage:

• Return2Start can relax the modeling and optimization effort when your business rule is simply “return to start between visits”.

This is often simpler than implementing a full pickup-and-delivery capacity model when:

• the only reason you go home is to reload/reset between visits,
• and you do not need fine-grained load tracking.

However, use full PND if you need:

• multiple goods types,
• partial fulfillment rules,
• timed transport SLAs (TimedLoad),
• flexible production/reloading (FlexLoads),
• or detailed depot reports.

Return2Start is best understood as:

• a direct architectural feature for depot-loop routing,
• not a substitute for full logistics inventory modeling.

Modeling patterns and best practices

Pattern A — Only some nodes require return to start

You do not have to apply Return2Start to every node.
You can apply it selectively, for example:

• hazardous deliveries require depot return,
• normal deliveries can chain directly.

Pattern B — Calibrate dwell time realistically

Set intermediateStayAtHomeDuration based on real operations:

• 5–10 minutes (quick restock),
• 15–30 minutes (loading paperwork, equipment reset),
• 60+ minutes (charging cycles).

Dwell time is a critical parameter because it influences:

• time-window feasibility,
• how many visits fit into a day,
• and whether the solver chooses certain nodes or not (if optional nodes exist).

Pattern C — Keep routes open unless you explicitly need end-of-day return

If your operation does not require returning home at the end of the day, model:

• open routes (as the example does),
• and rely on Return2Start for depot loops between visits.

If you do require depot return at day end:

• set closed routes for the relevant WorkingHours blocks.

Common pitfalls

Pitfall 1 — Confusing Return2Start with route termination

Return2Start inserts intermediate return legs; it is not “end the route”.

Pitfall 2 — Over-constraining the plan

Forcing depot return after many nodes can drastically increase travel time and reduce throughput. Use it only where it reflects a real business rule.

Pitfall 3 — Dwell time too small or too large

• Too small: unrealistic; can appear to “create time” at the depot.
• Too large: makes instances infeasible or reduces plan quality unnecessarily.

Summary

• Return2Start forces the resource to return to its start location between visits.
• It is enabled per node via setIsReturnStart(Duration).
• The duration represents mandatory time spent at the start location before continuing.
• Return2Start is not route termination; it inserts intermediate “return-to-depot” steps.
• It is particularly useful for depot-loop processes such as reloading and reset operations, and can simplify certain pickup/delivery patterns.