Views:

Question

How to parameterize a network and the Dynamic User Equilibrium (DUE) method correctly?

Answer

1) DUE uses Time series (and no VDF), creates approximations for them and needs sufficient interpolation points to be able to model these. For DUE this means: time intervals of one hour are too rough.
Therefore, intervals of 5 to 15 minutes are recommended.
2) Define enough time intervals so that all vehicles can leave the network.
Therefore: Think about a broad set of intervals for the vehicles to leave the network. If the rerouting goes beyond one day, you need the Calendar Add-on.
The last post-assignment Time interval must remain empty.
3) DUE treats Connectors, Turn and Links all as Links.
Capacities of Connectors, Turns and Links must therefore be realistically set to saturation traffic levels.
4) DUE models flows and can only do so correctly on real Links. Connectors at Nodes are always treated at last.
Therefore, it is recommended to connect Zones in the subordinate network, preferably to single-arm Nodes.
5) DUE does not know conflicting flows at Nodes (and therefore cannot be used in combination with ICA).
Therefore, any transfer of Node capacities to Links as known from static methods is not recommended. (If you want to do this, use the Dynamic Stochastic Assignment).
- Bottlenecks at Nodes, which are caused e.g. by Node control, should be modeled as Turn capacities. Congested Turn will lead to modeling blocking back, which in turn will restrict the flow to congested Links upstream.
- Use the Link attributes "DUE Out capacity PrT" and "DUE Use out capacity PrT" and remember that Outbound capacity = Link capacity x Green time.
- The route attribute "DUE Out capacity PrT" can also be used to correct the influence of mixed Lanes on Turn capacities. Mixed Lanes are not taken into account for the calculation of Turn capacities, which is why the sum of outbound Turns is estimated too optimistically. "DUE Out capacity PrT" must be defined if Turn capacities are not defined.
6) Congestion on Connectors over multiple Time intervals is a sign that network and demand do not match and should be considered a model error.
Therefore, e.g., Bars on Volume and Queue length are also helpful at Connectors to check this.
7) Blocking back is by definition chaotic, reduces convergence and overview for network faults. Only when all network faults are eliminated, effects due to blocking back can be modeled successfully.
Therefore it is recommended to calibrate without blocking back until you are sure to have a correct network and a stable assignment.