Tensions in Practice: Compact capacity planning in tension with timed feasibility¶
Parcel route · fixed departures and a deadline
A parcel leaves A at time 0 and reaches B at 2. A B-to-C trip departed at 1 and arrived at 3; the next leaves at 4 and arrives at 6. The parcel’s deadline is 5. An aggregate graph still contains A→B→C, with capacity on both legs. Adding time reveals why that connected route does not deliver this parcel before the deadline.
Keep the planning model compact
Represent overall routes and capacity without a separate state for every time point.
Check an executable itinerary
Respect the order of arrivals, departures and deadlines for a particular delivery.
Why these aims pull against each other
Aggregating the transfer location collapses its earlier and later states into one node. That simplification can connect legs that the parcel cannot actually take in sequence.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Use aggregate connectivity
Represent A, B and C once each, with a one-parcel capacity on each route during the planning period.
- What it protects
- The compact model exposes overall connectivity and aggregate capacity with few nodes.
- What it costs
- It cannot establish whether this parcel can reach the second departure or meet deadline 5.
- When it fits
- Fits preliminary network planning or steady-flow questions where the omitted schedule detail is genuinely irrelevant.
Illustration note: This option supplies a coarser planning answer, not a valid dispatch promise. Treating the drawn path as an on-time itinerary would misuse the model.
Keep time in the route
Represent the parcel reaching B at 2 separately from the earlier departure at 1. Its usable next trip arrives at C at 6.
- What it protects
- The missed connection and failed deadline are explicit; the model does not recommend an impossible itinerary.
- What it costs
- Time states and waiting relations enlarge the model and require accurate schedule data.
- When it fits
- Fits operational routing where arrival order and deadlines affect feasibility.
Illustration note: The graph compresses the wait from 2 to 4 into one labeled edge. Times and capacities are invented, and no route uncertainty or stochastic queue is modeled.
What this illustration does—and does not—establish
Network Flow Models: Static Flow vs Time-Dynamic Routing supplies the added time dimension and its size cost. The finite missed connection shows which relationship an aggregate place node cannot preserve.
- The time-aware option correctly finds failure for deadline 5; it does not create a faster service.
- A different departure schedule, deadline or origin time could change the result.
- The diagrams show a single parcel and do not establish a general optimization result.
Source entries
Network Flow Models
Network Flow Models: Static Flow vs Time-Dynamic Routing supplies the conflict examined here.
Static Flow vs Time-Dynamic Routing
Real routing and allocation problems have time dynamics: shipments arrive and depart on schedules, traffic patterns vary by hour, capacities vary over time, inventories build and deplete. Time-expanded networks (adding time as a dimension) extend the framework but multiply the network size by the number of time slices, often rendering previously-tractable problems intractable.
What It Is Not
- Not dynamic or time-varying by default — standard formulations are static; time-varying flow problems require either time-expanded networks (adding time as a dimension) or more-general dynamic-programming formulations.