# C++ Reference: routing

This documentation is automatically generated.

The vehicle routing library lets one model and solve generic vehicle routing problems ranging from the Traveling Salesman Problem to more complex problems such as the Capacitated Vehicle Routing Problem with Time Windows.The objective of a vehicle routing problem is to build routes covering a set of nodes minimizing the overall cost of the routes (usually proportional to the sum of the lengths of each segment of the routes) while respecting some problem-specific constraints (such as the length of a route). A route is equivalent to a path connecting nodes, starting/ending at specific starting/ending nodes.

The term "vehicle routing" is historical and the category of problems solved is not limited to the routing of vehicles: any problem involving finding routes visiting a given number of nodes optimally falls under this category of problems, such as finding the optimal sequence in a playlist. The literature around vehicle routing problems is extremely dense but one can find some basic introductions in the following links:

- http://en.wikipedia.org/wiki/Travelling_salesman_problem

- http://www.tsp.gatech.edu/history/index.html

- http://en.wikipedia.org/wiki/Vehicle_routing_problem

The vehicle routing library is a vertical layer above the constraint

programming library (ortools/constraint_programming:cp). One has access to all underlying constrained variables of the vehicle routing model which can therefore be enriched by adding any constraint available in the constraint programming library.

There are two sets of variables available:

- path variables:

* "next(i)" variables representing the immediate successor of the node

corresponding to i; use IndexToNode() to get the node corresponding to

a "next" variable value; note that node indices are strongly typed

integers (cf. ortools/base/int_type.h);

* "vehicle(i)" variables representing the vehicle route to which the

node corresponding to i belongs;

* "active(i)" boolean variables, true if the node corresponding to i is

visited and false if not; this can be false when nodes are either

optional or part of a disjunction;

* The following relationships hold for all i:

active(i) == 0 <=> next(i) == i <=> vehicle(i) == -1,

next(i) == j => vehicle(j) == vehicle(i).

- dimension variables, used when one is accumulating quantities along

routes, such as weight or volume carried, distance or time:

* "cumul(i,d)" variables representing the quantity of dimension d when

arriving at the node corresponding to i;

* "transit(i,d)" variables representing the quantity of dimension d added

after visiting the node corresponding to i.

* The following relationship holds for all (i,d):

next(i) == j => cumul(j,d) == cumul(i,d) + transit(i,d). Solving the vehicle routing problems is mainly done using approximate

methods (namely local search, cf. http://en.wikipedia.org/wiki/Local_search_(optimization) ), potentially combined with exact techniques based on dynamic programming and exhaustive tree search. TODO(user): Add a section on costs (vehicle arc costs, span costs, disjunctions costs).

Advanced tips: Flags are available to tune the search used to solve routing problems. Here is a quick overview of the ones one might want to modify:

- Limiting the search for solutions:

* routing_solution_limit (default: kint64max): stop the search after

finding 'routing_solution_limit' improving solutions;

* routing_time_limit (default: kint64max): stop the search after

'routing_time_limit' milliseconds;

- Customizing search:

* routing_first_solution (default: select the first node with an unbound

successor and connect it to the first available node): selects the

heuristic to build a first solution which will then be improved by local

search; possible values are GlobalCheapestArc (iteratively connect two

nodes which produce the cheapest route segment), LocalCheapestArc

(select the first node with an unbound successor and connect it to the

node which produces the cheapest route segment), PathCheapestArc

(starting from a route "start" node, connect it to the node which

produces the cheapest route segment, then extend the route by iterating

on the last node added to the route).

* Local search neighborhoods:

- routing_no_lns (default: false): forbids the use of Large Neighborhood

Search (LNS); LNS can find good solutions but is usually very slow.

Refer to the description of PATHLNS in the LocalSearchOperators enum

in constraint_solver.h for more information.

- routing_no_tsp (default: true): forbids the use of exact methods to

solve "sub"-traveling salesman problems (TSPs) of the current model

(such as sub-parts of a route, or one route in a multiple route

problem). Uses dynamic programming to solve such TSPs with a maximum

size (in number of nodes) up to cp_local_search_tsp_opt_size (flag

with a default value of 13 nodes). It is not activated by default

because it can slow down the search.

* Meta-heuristics: used to guide the search out of local minima found by

local search. Note that, in general, a search with metaheuristics

activated never stops, therefore one must specify a search limit.

Several types of metaheuristics are provided:

- routing_guided_local_search (default: false): activates guided local

search (cf. http://en.wikipedia.org/wiki/Guided_Local_Search);

this is generally the most efficient metaheuristic for vehicle

routing;

- routing_simulated_annealing (default: false): activates simulated

annealing (cf. http://en.wikipedia.org/wiki/Simulated_annealing);

- routing_tabu_search (default: false): activates tabu search (cf.

http://en.wikipedia.org/wiki/Tabu_search).

Code sample:

Here is a simple example solving a traveling salesman problem given a cost function callback (returns the cost of a route segment):

- Define a custom distance/cost function from an index to another; in this

example just returns the sum of the indices:

int64_t MyDistance(int64_t from, int64_t to) {

return from + to;

}

- Create a routing model for a given problem size (int number of nodes) and

number of routes (here, 1):

RoutingIndexManager manager(...number of nodes..., 1); RoutingModel routing(manager);- Set the cost function by registering an std::function<int64_t(int64_t, int64_t)> in the model and passing its index as the vehicle cost.

const int cost = routing.RegisterTransitCallback(MyDistance); routing.SetArcCostEvaluatorOfAllVehicles(cost);

- Find a solution using Solve(), returns a solution if any (owned by

routing):

const Assignment* solution = routing.Solve(); CHECK(solution != nullptr);- Inspect the solution cost and route (only one route here):

LOG(INFO) << "Cost " << solution->ObjectiveValue(); const int route_number = 0; for (int64_t node = routing.Start(route_number); !routing.IsEnd(node); node = solution->Value(routing.NextVar(node))) { LOG(INFO) << manager.IndexToNode(node); }Keywords: Vehicle Routing, Traveling Salesman Problem, TSP, VRP, CVRPTW,

PDP.