C++ Reference: routing

Note: 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://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.

Classes

DisjunctivePropagator
GlobalVehicleBreaksConstraint
RoutingDimension
RoutingModel
RoutingModelVisitor
SimpleBoundCosts
TypeIncompatibilityChecker
TypeRegulationsChecker
TypeRegulationsConstraint
TypeRequirementChecker