OR-Tools  9.1
min_cost_flow.h
Go to the documentation of this file.
1 // Copyright 2010-2021 Google LLC
2 // Licensed under the Apache License, Version 2.0 (the "License");
3 // you may not use this file except in compliance with the License.
4 // You may obtain a copy of the License at
5 //
6 // http://www.apache.org/licenses/LICENSE-2.0
7 //
8 // Unless required by applicable law or agreed to in writing, software
9 // distributed under the License is distributed on an "AS IS" BASIS,
10 // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
11 // See the License for the specific language governing permissions and
12 // limitations under the License.
13 
14 // An implementation of a cost-scaling push-relabel algorithm for
15 // the min-cost flow problem.
16 //
17 // In the following, we consider a graph G = (V,E) where V denotes the set
18 // of nodes (vertices) in the graph, E denotes the set of arcs (edges).
19 // n = |V| denotes the number of nodes in the graph, and m = |E| denotes the
20 // number of arcs in the graph.
21 //
22 // With each arc (v,w) is associated a nonnegative capacity u(v,w)
23 // (where 'u' stands for "upper bound") and a unit cost c(v,w). With
24 // each node v is associated a quantity named supply(v), which
25 // represents a supply of fluid (if >0) or a demand (if <0).
26 // Furthermore, no fluid is created in the graph so
27 // sum_{v in V} supply(v) = 0.
28 //
29 // A flow is a function from E to R such that:
30 // a) f(v,w) <= u(v,w) for all (v,w) in E (capacity constraint).
31 // b) f(v,w) = -f(w,v) for all (v,w) in E (flow antisymmetry constraint).
32 // c) sum on v f(v,w) + supply(w) = 0 (flow conservation).
33 //
34 // The cost of a flow is sum on (v,w) in E ( f(v,w) * c(v,w) ) [Note:
35 // It can be confusing to beginners that the cost is actually double
36 // the amount that it might seem at first because of flow
37 // antisymmetry.]
38 //
39 // The problem to solve: find a flow of minimum cost such that all the
40 // fluid flows from the supply nodes to the demand nodes.
41 //
42 // The principles behind this algorithm are the following:
43 // 1/ handle pseudo-flows instead of flows and refine pseudo-flows until an
44 // epsilon-optimal minimum-cost flow is obtained,
45 // 2/ deal with epsilon-optimal pseudo-flows.
46 //
47 // 1/ A pseudo-flow is like a flow, except that a node's outflow minus
48 // its inflow can be different from its supply. If it is the case at a
49 // given node v, it is said that there is an excess (or deficit) at
50 // node v. A deficit is denoted by a negative excess and inflow =
51 // outflow + excess.
52 // (Look at ortools/graph/max_flow.h to see that the definition
53 // of preflow is more restrictive than the one for pseudo-flow in that a preflow
54 // only allows non-negative excesses, i.e., no deficit.)
55 // More formally, a pseudo-flow is a function f such that:
56 // a) f(v,w) <= u(v,w) for all (v,w) in E (capacity constraint).
57 // b) f(v,w) = -f(w,v) for all (v,w) in E (flow antisymmetry constraint).
58 //
59 // For each v in E, we also define the excess at node v, the algebraic sum of
60 // all the incoming preflows at this node, added together with the supply at v.
61 // excess(v) = sum on u f(u,v) + supply(v)
62 //
63 // The goal of the algorithm is to obtain excess(v) = 0 for all v in V, while
64 // consuming capacity on some arcs, at the lowest possible cost.
65 //
66 // 2/ Internally to the algorithm and its analysis (but invisibly to
67 // the client), each node has an associated "price" (or potential), in
68 // addition to its excess. It is formally a function from E to R (the
69 // set of real numbers.). For a given price function p, the reduced
70 // cost of an arc (v,w) is:
71 // c_p(v,w) = c(v,w) + p(v) - p(w)
72 // (c(v,w) is the cost of arc (v,w).) For those familiar with linear
73 // programming, the price function can be viewed as a set of dual
74 // variables.
75 //
76 // For a constant epsilon >= 0, a pseudo-flow f is said to be epsilon-optimal
77 // with respect to a price function p if for every residual arc (v,w) in E,
78 // c_p(v,w) >= -epsilon.
79 //
80 // A flow f is optimal if and only if there exists a price function p such that
81 // no arc is admissible with respect to f and p.
82 //
83 // If the arc costs are integers, and epsilon < 1/n, any epsilon-optimal flow
84 // is optimal. The integer cost case is handled by multiplying all the arc costs
85 // and the initial value of epsilon by (n+1). When epsilon reaches 1, and
86 // the solution is epsilon-optimal, it means: for all residual arc (v,w) in E,
87 // (n+1) * c_p(v,w) >= -1, thus c_p(v,w) >= -1/(n+1) >= 1/n, and the
88 // solution is optimal.
89 //
90 // A node v is said to be *active* if excess(v) > 0.
91 // In this case the following operations can be applied to it:
92 // - if there are *admissible* incident arcs, i.e. arcs which are not saturated,
93 // and whose reduced costs are negative, a PushFlow operation can
94 // be applied. It consists in sending as much flow as both the excess at the
95 // node and the capacity of the arc permit.
96 // - if there are no admissible arcs, the active node considered is relabeled,
97 // This is implemented in Discharge, which itself calls PushFlow and Relabel.
98 //
99 // Discharge itself is called by Refine. Refine first saturates all the
100 // admissible arcs, then builds a stack of active nodes. It then applies
101 // Discharge for each active node, possibly adding new ones in the process,
102 // until no nodes are active. In that case an epsilon-optimal flow is obtained.
103 //
104 // Optimize iteratively calls Refine, while epsilon > 1, and divides epsilon by
105 // alpha (set by default to 5) before each iteration.
106 //
107 // The algorithm starts with epsilon = C, where C is the maximum absolute value
108 // of the arc costs. In the integer case which we are dealing with, since all
109 // costs are multiplied by (n+1), the initial value of epsilon is (n+1)*C.
110 // The algorithm terminates when epsilon = 1, and Refine() has been called.
111 // In this case, a minimum-cost flow is obtained.
112 //
113 // The complexity of the algorithm is O(n^2*m*log(n*C)) where C is the value of
114 // the largest arc cost in the graph.
115 //
116 // IMPORTANT:
117 // The algorithm is not able to detect the infeasibility of a problem (i.e.,
118 // when a bottleneck in the network prohibits sending all the supplies.)
119 // Worse, it could in some cases loop forever. This is why feasibility checking
120 // is enabled by default (FLAGS_min_cost_flow_check_feasibility=true.)
121 // Feasibility checking is implemented using a max-flow, which has a much lower
122 // complexity. The impact on performance is negligible, while the risk of being
123 // caught in an endless loop is removed. Note that using the feasibility checker
124 // roughly doubles the memory consumption.
125 //
126 // The starting reference for this class of algorithms is:
127 // A.V. Goldberg and R.E. Tarjan, "Finding Minimum-Cost Circulations by
128 // Successive Approximation." Mathematics of Operations Research, Vol. 15,
129 // 1990:430-466.
130 // http://portal.acm.org/citation.cfm?id=92225
131 //
132 // Implementation issues are tackled in:
133 // A.V. Goldberg, "An Efficient Implementation of a Scaling Minimum-Cost Flow
134 // Algorithm," Journal of Algorithms, (1997) 22:1-29
135 // http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.258
136 //
137 // A.V. Goldberg and M. Kharitonov, "On Implementing Scaling Push-Relabel
138 // Algorithms for the Minimum-Cost Flow Problem", Network flows and matching:
139 // First DIMACS implementation challenge, DIMACS Series in Discrete Mathematics
140 // and Theoretical Computer Science, (1993) 12:157-198.
141 // ftp://dimacs.rutgers.edu/pub/netflow/submit/papers/Goldberg-mincost/scalmin.ps
142 // and in:
143 // U. Bunnagel, B. Korte, and J. Vygen. “Efficient implementation of the
144 // Goldberg-Tarjan minimum-cost flow algorithm.” Optimization Methods and
145 // Software (1998) vol. 10, no. 2:157-174.
146 // http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.84.9897
147 //
148 // We have tried as much as possible in this implementation to keep the
149 // notations and namings of the papers cited above, except for 'demand' or
150 // 'balance' which have been replaced by 'supply', with the according sign
151 // changes to better accommodate with the API of the rest of our tools. A demand
152 // is denoted by a negative supply.
153 //
154 // TODO(user): See whether the following can bring any improvements on real-life
155 // problems.
156 // R.K. Ahuja, A.V. Goldberg, J.B. Orlin, and R.E. Tarjan, "Finding minimum-cost
157 // flows by double scaling," Mathematical Programming, (1992) 53:243-266.
158 // http://www.springerlink.com/index/gu7404218u6kt166.pdf
159 //
160 // An interesting general reference on network flows is:
161 // R. K. Ahuja, T. L. Magnanti, J. B. Orlin, "Network Flows: Theory, Algorithms,
162 // and Applications," Prentice Hall, 1993, ISBN: 978-0136175490,
163 // http://www.amazon.com/dp/013617549X
164 //
165 // Keywords: Push-relabel, min-cost flow, network, graph, Goldberg, Tarjan,
166 // Dinic, Dinitz.
167 
168 #ifndef OR_TOOLS_GRAPH_MIN_COST_FLOW_H_
169 #define OR_TOOLS_GRAPH_MIN_COST_FLOW_H_
170 
171 #include <algorithm>
172 #include <cstdint>
173 #include <stack>
174 #include <string>
175 #include <vector>
176 
178 #include "ortools/base/logging.h"
179 #include "ortools/base/macros.h"
181 #include "ortools/graph/graph.h"
182 #include "ortools/util/stats.h"
183 #include "ortools/util/zvector.h"
184 
185 namespace operations_research {
186 
187 // Forward declaration.
188 template <typename Graph, typename ArcFlowType, typename ArcScaledCostType>
190 
191 // Different statuses for a solved problem.
192 // We use a base class to share it between our different interfaces.
194  public:
195  enum Status {
203  };
204 };
205 
206 // A simple and efficient min-cost flow interface. This is as fast as
207 // GenericMinCostFlow<ReverseArcStaticGraph>, which is the fastest, but is uses
208 // more memory in order to hide the somewhat involved construction of the
209 // static graph.
210 //
211 // TODO(user): If the need arises, extend this interface to support warm start
212 // and incrementality between solves. Note that this is already supported by the
213 // GenericMinCostFlow<> interface.
215  public:
216  // By default, the constructor takes no size. New node indices are created
217  // lazily by AddArcWithCapacityAndUnitCost() or SetNodeSupply() such that the
218  // set of valid nodes will always be [0, NumNodes()).
219  //
220  // You may pre-reserve the internal data structures with a given expected
221  // number of nodes and arcs, to potentially gain performance.
222  explicit SimpleMinCostFlow(NodeIndex reserve_num_nodes = 0,
223  ArcIndex reserve_num_arcs = 0);
224 
225  // Adds a directed arc from tail to head to the underlying graph with
226  // a given capacity and cost per unit of flow.
227  // * Node indices and the capacity must be non-negative (>= 0).
228  // * The unit cost can take any integer value (even negative).
229  // * Self-looping and duplicate arcs are supported.
230  // * After the method finishes, NumArcs() == the returned ArcIndex + 1.
233  CostValue unit_cost);
234 
235  // Sets the supply of the given node. The node index must be non-negative (>=
236  // 0). Nodes implicitly created will have a default supply set to 0. A demand
237  // is modeled as a negative supply.
238  void SetNodeSupply(NodeIndex node, FlowQuantity supply);
239 
240  // Solves the problem, and returns the problem status. This function
241  // requires that the sum of all node supply minus node demand is zero and
242  // that the graph has enough capacity to send all supplies and serve all
243  // demands. Otherwise, it will return INFEASIBLE.
245  return SolveWithPossibleAdjustment(SupplyAdjustment::DONT_ADJUST);
246  }
247 
248  // Same as Solve(), but does not have the restriction that the supply
249  // must match the demand or that the graph has enough capacity to serve
250  // all the demand or use all the supply. This will compute a maximum-flow
251  // with minimum cost. The value of the maximum-flow will be given by
252  // MaximumFlow().
254  return SolveWithPossibleAdjustment(SupplyAdjustment::ADJUST);
255  }
256 
257  // Returns the cost of the minimum-cost flow found by the algorithm when
258  // the returned Status is OPTIMAL.
259  CostValue OptimalCost() const;
260 
261  // Returns the total flow of the minimum-cost flow found by the algorithm
262  // when the returned Status is OPTIMAL.
263  FlowQuantity MaximumFlow() const;
264 
265  // Returns the flow on arc, this only make sense for a successful Solve().
266  //
267  // Note: It is possible that there is more than one optimal solution. The
268  // algorithm is deterministic so it will always return the same solution for
269  // a given problem. However, there is no guarantee of this from one code
270  // version to the next (but the code does not change often).
271  FlowQuantity Flow(ArcIndex arc) const;
272 
273  // Accessors for the user given data. The implementation will crash if "arc"
274  // is not in [0, NumArcs()) or "node" is not in [0, NumNodes()).
275  NodeIndex NumNodes() const;
276  ArcIndex NumArcs() const;
277  NodeIndex Tail(ArcIndex arc) const;
278  NodeIndex Head(ArcIndex arc) const;
279  FlowQuantity Capacity(ArcIndex arc) const;
280  FlowQuantity Supply(NodeIndex node) const;
281  CostValue UnitCost(ArcIndex arc) const;
282 
283  private:
284  typedef ::util::ReverseArcStaticGraph<NodeIndex, ArcIndex> Graph;
285  enum SupplyAdjustment { ADJUST, DONT_ADJUST };
286 
287  // Applies the permutation in arc_permutation_ to the given arc index.
288  ArcIndex PermutedArc(ArcIndex arc);
289  // Solves the problem, potentially applying supply and demand adjustment,
290  // and returns the problem status.
291  Status SolveWithPossibleAdjustment(SupplyAdjustment adjustment);
292  void ResizeNodeVectors(NodeIndex node);
293 
294  std::vector<NodeIndex> arc_tail_;
295  std::vector<NodeIndex> arc_head_;
296  std::vector<FlowQuantity> arc_capacity_;
297  std::vector<FlowQuantity> node_supply_;
298  std::vector<CostValue> arc_cost_;
299  std::vector<ArcIndex> arc_permutation_;
300  std::vector<FlowQuantity> arc_flow_;
301  CostValue optimal_cost_;
302  FlowQuantity maximum_flow_;
303 
304  DISALLOW_COPY_AND_ASSIGN(SimpleMinCostFlow);
305 };
306 
307 // Generic MinCostFlow that works with StarGraph and all the graphs handling
308 // reverse arcs from graph.h, see the end of min_cost_flow.cc for the exact
309 // types this class is compiled for.
310 //
311 // One can greatly decrease memory usage by using appropriately small integer
312 // types:
313 // - For the Graph<> types, i.e. NodeIndexType and ArcIndexType, see graph.h.
314 // - ArcFlowType is used for the *per-arc* flow quantity. It must be signed, and
315 // large enough to hold the maximum arc capacity and its negation.
316 // - ArcScaledCostType is used for a per-arc scaled cost. It must be signed
317 // and large enough to hold the maximum unit cost of an arc times
318 // (num_nodes + 1).
319 //
320 // Note that the latter two are different than FlowQuantity and CostValue, which
321 // are used for global, aggregated values and may need to be larger.
322 //
323 // TODO(user): Avoid using the globally defined type CostValue and FlowQuantity.
324 // Also uses the Arc*Type where there is no risk of overflow in more places.
325 template <typename Graph, typename ArcFlowType = FlowQuantity,
326  typename ArcScaledCostType = CostValue>
327 class GenericMinCostFlow : public MinCostFlowBase {
328  public:
329  typedef typename Graph::NodeIndex NodeIndex;
330  typedef typename Graph::ArcIndex ArcIndex;
331  typedef typename Graph::OutgoingArcIterator OutgoingArcIterator;
332  typedef typename Graph::OutgoingOrOppositeIncomingArcIterator
335 
336  // Initialize a MinCostFlow instance on the given graph. The graph does not
337  // need to be fully built yet, but its capacity reservation is used to
338  // initialize the memory of this class.
339  explicit GenericMinCostFlow(const Graph* graph);
340 
341  // Returns the graph associated to the current object.
342  const Graph* graph() const { return graph_; }
343 
344  // Returns the status of last call to Solve(). NOT_SOLVED is returned if
345  // Solve() has never been called or if the problem has been modified in such a
346  // way that the previous solution becomes invalid.
347  Status status() const { return status_; }
348 
349  // Sets the supply corresponding to node. A demand is modeled as a negative
350  // supply.
351  void SetNodeSupply(NodeIndex node, FlowQuantity supply);
352 
353  // Sets the unit cost for the given arc.
354  void SetArcUnitCost(ArcIndex arc, ArcScaledCostType unit_cost);
355 
356  // Sets the capacity for the given arc.
357  void SetArcCapacity(ArcIndex arc, ArcFlowType new_capacity);
358 
359  // Sets the flow for the given arc. Note that new_flow must be smaller than
360  // the capacity of the arc.
361  void SetArcFlow(ArcIndex arc, ArcFlowType new_flow);
362 
363  // Solves the problem, returning true if a min-cost flow could be found.
364  bool Solve();
365 
366  // Checks for feasibility, i.e., that all the supplies and demands can be
367  // matched without exceeding bottlenecks in the network.
368  // If infeasible_supply_node (resp. infeasible_demand_node) are not NULL,
369  // they are populated with the indices of the nodes where the initial supplies
370  // (resp. demands) are too large. Feasible values for the supplies and
371  // demands are accessible through FeasibleSupply.
372  // Note that CheckFeasibility is called by Solve() when the flag
373  // min_cost_flow_check_feasibility is set to true (which is the default.)
374  bool CheckFeasibility(std::vector<NodeIndex>* const infeasible_supply_node,
375  std::vector<NodeIndex>* const infeasible_demand_node);
376 
377  // Makes the min-cost flow problem solvable by truncating supplies and
378  // demands to a level acceptable by the network. There may be several ways to
379  // do it. In our case, the levels are computed from the result of the max-flow
380  // algorithm run in CheckFeasibility().
381  // MakeFeasible returns false if CheckFeasibility() was not called before.
382  bool MakeFeasible();
383 
384  // Returns the cost of the minimum-cost flow found by the algorithm.
385  CostValue GetOptimalCost() const { return total_flow_cost_; }
386 
387  // Returns the flow on the given arc using the equations given in the
388  // comment on residual_arc_capacity_.
389  FlowQuantity Flow(ArcIndex arc) const;
390 
391  // Returns the capacity of the given arc.
392  FlowQuantity Capacity(ArcIndex arc) const;
393 
394  // Returns the unscaled cost for the given arc.
395  CostValue UnitCost(ArcIndex arc) const;
396 
397  // Returns the supply at a given node. Demands are modelled as negative
398  // supplies.
399  FlowQuantity Supply(NodeIndex node) const;
400 
401  // Returns the initial supply at a given node.
403 
404  // Returns the largest supply (if > 0) or largest demand in absolute value
405  // (if < 0) admissible at node. If the problem is not feasible, some of these
406  // values will be smaller (in absolute value) than the initial supplies
407  // and demand given as input.
409 
410  // Whether to use the UpdatePrices() heuristic.
411  void SetUseUpdatePrices(bool value) { use_price_update_ = value; }
412 
413  // Whether to check the feasibility of the problem with a max-flow, prior to
414  // solving it. This uses about twice as much memory, but detects infeasible
415  // problems (where the flow can't be satisfied) and makes Solve() return
416  // INFEASIBLE. If you disable this check, you will spare memory but you must
417  // make sure that your problem is feasible, otherwise the code can loop
418  // forever.
419  void SetCheckFeasibility(bool value) { check_feasibility_ = value; }
420 
421  private:
422  // Returns true if the given arc is admissible i.e. if its residual capacity
423  // is strictly positive, and its reduced cost strictly negative, i.e., pushing
424  // more flow into it will result in a reduction of the total cost.
425  bool IsAdmissible(ArcIndex arc) const;
426  bool FastIsAdmissible(ArcIndex arc, CostValue tail_potential) const;
427 
428  // Returns true if node is active, i.e., if its supply is positive.
429  bool IsActive(NodeIndex node) const;
430 
431  // Returns the reduced cost for a given arc.
432  CostValue ReducedCost(ArcIndex arc) const;
433  CostValue FastReducedCost(ArcIndex arc, CostValue tail_potential) const;
434 
435  // Returns the first incident arc of a given node.
436  ArcIndex GetFirstOutgoingOrOppositeIncomingArc(NodeIndex node) const;
437 
438  // Checks the consistency of the input, i.e., whether the sum of the supplies
439  // for all nodes is equal to zero. To be used in a DCHECK.
440  bool CheckInputConsistency() const;
441 
442  // Checks whether the result is valid, i.e. whether for each arc,
443  // residual_arc_capacity_[arc] == 0 || ReducedCost(arc) >= -epsilon_.
444  // (A solution is epsilon-optimal if ReducedCost(arc) >= -epsilon.)
445  // To be used in a DCHECK.
446  bool CheckResult() const;
447 
448  // Checks that the cost range fits in the range of int64_t's.
449  // To be used in a DCHECK.
450  bool CheckCostRange() const;
451 
452  // Checks the relabel precondition (to be used in a DCHECK):
453  // - The node must be active, or have a 0 excess (relaxation for the Push
454  // Look-Ahead heuristic).
455  // - The node must have no admissible arcs.
456  bool CheckRelabelPrecondition(NodeIndex node) const;
457 
458  // Returns context concatenated with information about a given arc
459  // in a human-friendly way.
460  std::string DebugString(const std::string& context, ArcIndex arc) const;
461 
462  // Resets the first_admissible_arc_ array to the first incident arc of each
463  // node.
464  void ResetFirstAdmissibleArcs();
465 
466  // Scales the costs, by multiplying them by (graph_->num_nodes() + 1).
467  void ScaleCosts();
468 
469  // Unscales the costs, by dividing them by (graph_->num_nodes() + 1).
470  void UnscaleCosts();
471 
472  // Optimizes the cost by dividing epsilon_ by alpha_ and calling Refine().
473  void Optimize();
474 
475  // Saturates the admissible arcs, i.e., push as much flow as possible.
476  void SaturateAdmissibleArcs();
477 
478  // Pushes flow on a given arc, i.e., consumes flow on
479  // residual_arc_capacity_[arc], and consumes -flow on
480  // residual_arc_capacity_[Opposite(arc)]. Updates node_excess_ at the tail
481  // and head of the arc accordingly.
482  void PushFlow(FlowQuantity flow, ArcIndex arc);
483  void FastPushFlow(FlowQuantity flow, ArcIndex arc, NodeIndex tail);
484 
485  // Initializes the stack active_nodes_.
486  void InitializeActiveNodeStack();
487 
488  // Price update heuristics as described in A.V. Goldberg, "An Efficient
489  // Implementation of a Scaling Minimum-Cost Flow Algorithm," Journal of
490  // Algorithms, (1997) 22:1-29
491  // http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.258
492  void UpdatePrices();
493 
494  // Performs an epsilon-optimization step by saturating admissible arcs
495  // and discharging the active nodes.
496  void Refine();
497 
498  // Discharges an active node by saturating its admissible adjacent arcs,
499  // if any, and by relabelling it when it becomes inactive.
500  void Discharge(NodeIndex node);
501 
502  // Part of the Push LookAhead heuristic. When we are about to push on the
503  // in_arc, we check that the head (i.e node here) can accept the flow and
504  // return true if this is the case:
505  // - Returns true if the node excess is < 0.
506  // - Returns true if node is an admissible arc at its current potential.
507  // - If the two conditions above are false, the node can be relabeled. We
508  // do that and return true if the in_arc is still admissible.
509  bool LookAhead(ArcIndex in_arc, CostValue in_tail_potential, NodeIndex node);
510 
511  // Relabels node, i.e., decreases its potential while keeping the
512  // epsilon-optimality of the pseudo flow. See CheckRelabelPrecondition() for
513  // details on the preconditions.
514  void Relabel(NodeIndex node);
515 
516  // Handy member functions to make the code more compact.
517  NodeIndex Head(ArcIndex arc) const { return graph_->Head(arc); }
518  NodeIndex Tail(ArcIndex arc) const { return graph_->Tail(arc); }
519  ArcIndex Opposite(ArcIndex arc) const;
520  bool IsArcDirect(ArcIndex arc) const;
521  bool IsArcValid(ArcIndex arc) const;
522 
523  // Pointer to the graph passed as argument.
524  const Graph* graph_;
525 
526  // An array representing the supply (if > 0) or the demand (if < 0)
527  // for each node in graph_.
528  QuantityArray node_excess_;
529 
530  // An array representing the potential (or price function) for
531  // each node in graph_.
532  CostArray node_potential_;
533 
534  // An array representing the residual_capacity for each arc in graph_.
535  // Residual capacities enable one to represent the capacity and flow for all
536  // arcs in the graph in the following manner.
537  // For all arcs, residual_arc_capacity_[arc] = capacity[arc] - flow[arc]
538  // Moreover, for reverse arcs, capacity[arc] = 0 by definition.
539  // Also flow[Opposite(arc)] = -flow[arc] by definition.
540  // Therefore:
541  // - for a direct arc:
542  // flow[arc] = 0 - flow[Opposite(arc)]
543  // = capacity[Opposite(arc)] - flow[Opposite(arc)]
544  // = residual_arc_capacity_[Opposite(arc)]
545  // - for a reverse arc:
546  // flow[arc] = -residual_arc_capacity_[arc]
547  // Using these facts enables one to only maintain residual_arc_capacity_,
548  // instead of both capacity and flow, for each direct and indirect arc. This
549  // reduces the amount of memory for this information by a factor 2.
550  // Note that the sum of the largest capacity of an arc in the graph and of
551  // the total flow in the graph mustn't exceed the largest 64 bit integer
552  // to avoid errors. CheckInputConsistency() verifies this constraint.
553  ZVector<ArcFlowType> residual_arc_capacity_;
554 
555  // An array representing the first admissible arc for each node in graph_.
556  ArcIndexArray first_admissible_arc_;
557 
558  // A stack used for managing active nodes in the algorithm.
559  // Note that the papers cited above recommend the use of a queue, but
560  // benchmarking so far has not proved it is better.
561  std::stack<NodeIndex> active_nodes_;
562 
563  // epsilon_ is the tolerance for optimality.
564  CostValue epsilon_;
565 
566  // alpha_ is the factor by which epsilon_ is divided at each iteration of
567  // Refine().
568  const int64_t alpha_;
569 
570  // cost_scaling_factor_ is the scaling factor for cost.
571  CostValue cost_scaling_factor_;
572 
573  // An array representing the scaled unit cost for each arc in graph_.
574  ZVector<ArcScaledCostType> scaled_arc_unit_cost_;
575 
576  // The total cost of the flow.
577  CostValue total_flow_cost_;
578 
579  // The status of the problem.
580  Status status_;
581 
582  // An array containing the initial excesses (i.e. the supplies) for each
583  // node. This is used to create the max-flow-based feasibility checker.
584  QuantityArray initial_node_excess_;
585 
586  // An array containing the best acceptable excesses for each of the
587  // nodes. These excesses are imposed by the result of the max-flow-based
588  // feasibility checker for the nodes with an initial supply != 0. For the
589  // other nodes, the excess is simply 0.
590  QuantityArray feasible_node_excess_;
591 
592  // Statistics about this class.
593  StatsGroup stats_;
594 
595  // Number of Relabel() since last UpdatePrices().
596  int num_relabels_since_last_price_update_;
597 
598  // A Boolean which is true when feasibility has been checked.
599  bool feasibility_checked_;
600 
601  // Whether to use the UpdatePrices() heuristic.
602  bool use_price_update_;
603 
604  // Whether to check the problem feasibility with a max-flow.
605  bool check_feasibility_;
606 
607  DISALLOW_COPY_AND_ASSIGN(GenericMinCostFlow);
608 };
609 
610 #if !SWIG
611 
612 // Default MinCostFlow instance that uses StarGraph.
613 // New clients should use SimpleMinCostFlow if they can.
614 class MinCostFlow : public GenericMinCostFlow<StarGraph> {
615  public:
617 };
618 
619 #endif // SWIG
620 
621 } // namespace operations_research
622 #endif // OR_TOOLS_GRAPH_MIN_COST_FLOW_H_
int64_t head
Graph::OutgoingArcIterator OutgoingArcIterator
FlowQuantity FeasibleSupply(NodeIndex node) const
void SetNodeSupply(NodeIndex node, FlowQuantity supply)
FlowQuantity Capacity(ArcIndex arc) const
FlowQuantity Capacity(ArcIndex arc) const
FlowQuantity Flow(ArcIndex arc) const
CostValue UnitCost(ArcIndex arc) const
int64_t tail
void SetArcCapacity(ArcIndex arc, ArcFlowType new_capacity)
NodeIndex Tail(ArcIndex arc) const
ZVector< FlowQuantity > QuantityArray
Definition: ebert_graph.h:210
FlowQuantity Supply(NodeIndex node) const
SimpleMinCostFlow(NodeIndex reserve_num_nodes=0, ArcIndex reserve_num_arcs=0)
ZVector< CostValue > CostArray
Definition: ebert_graph.h:211
MinCostFlow(const StarGraph *graph)
void SetArcFlow(ArcIndex arc, ArcFlowType new_flow)
int64_t capacity
FlowQuantity Flow(ArcIndex arc) const
FlowQuantity InitialSupply(NodeIndex node) const
FlowQuantity Supply(NodeIndex node) const
ListGraph Graph
Definition: graph.h:2361
void SetArcUnitCost(ArcIndex arc, ArcScaledCostType unit_cost)
NodeIndex Head(ArcIndex arc) const
Collection of objects used to extend the Constraint Solver library.
GurobiMPCallbackContext * context
Graph::OutgoingOrOppositeIncomingArcIterator OutgoingOrOppositeIncomingArcIterator
CostValue UnitCost(ArcIndex arc) const
int64_t value
ArcIndex AddArcWithCapacityAndUnitCost(NodeIndex tail, NodeIndex head, FlowQuantity capacity, CostValue unit_cost)
void SetNodeSupply(NodeIndex node, FlowQuantity supply)
bool CheckFeasibility(std::vector< NodeIndex > *const infeasible_supply_node, std::vector< NodeIndex > *const infeasible_demand_node)