Skip to content

Latest commit

 

History

History
40 lines (23 loc) · 4.51 KB

vdf.md

File metadata and controls

40 lines (23 loc) · 4.51 KB
Raw

VDF Module

The following describes how volume-delay-functions (VDF) can be used in eqasim. There are several shortcomings with the queue-based simulation of MATSim, especially when thinking, for instance, of spillback from a city network onto highways and similar phenomena. This could be covered by lanes in MATSim, but this functionality does not seem to be widely used and data acquisition seems tricky.

Therefore, we propose to simply treat each link in the network as a line that needs to be traversed by all vehicles with a specific duration. This duration, as in the classic BPR function, is directly dependent on the flow on that link. Our idea is now to track the flow on each link from the previous iteration(s) and then impose the calculated travel time. The same travel time is used in the routing and decision-making, so that agents will avoid using links with high flow relative to its capacity, because traversal times are high.

VDF Module

The main components of this extension are the VDF(QSim)Module and the VDFConfigGroup. The interval on which flows are evaluated can be configured, but is set to one hour by default. The volume-delay-function used is the classic BPR function that calculates a traversal time based on the free-flow traversal time and the ratio between detected flow and link capacity.

For the VDF functionality to work:

  • Set the storage capacity of all links to infinity (1e9), we effectively disable the queue logic using the storageCapacityFactor in the QSim configuration
  • Set the flow capacity of all links to infinity (1e9), we effectively disable the queue logic using the flowCapacityFactor in the QSim configuration
  • Remove car from the mainModes in the QSim configuration
  • Add VDFModule and VDFQSimModule

On the technical side, the logic is that the VDF component tracks link enter/leave events and thus established the flows on the links. Based on those flows, the traversal times are calculated and bound via TravelTime. This travel time is then used by the standard network routing modules for the relevant modes.

Note that it would be unstable to always use the flows of the previous iteration. Therefore, we interpolate over multiple iterations. There are various ways of doing so, by default we use a horizon-based approach in which we track the flows on all links over N (default 10) iterations and then calculate the mean (MA, moving average approach). Another approach is to always blend between the flows of the previous iteration and the current one (AR, auto-regressive approach). It can be selected in the config group.

Furthermore, averaging over multiple iterations means that we need to recover this state if we want to restart a simulation later on at a specific iteration. The config group provides a inputFile parameter that does exactly this, based on the VDF output of a previous simulation.

The binary output can be controlled by setting writeInterval in the config group. If set to a very large value, only the last iteration will be saved. Optionally, a file containing the flows on all links will be generated by setting writeFlowInterval.

Attention: The VDF (default BPR) is defined for a full-size simulation, and so are the capacities in the network. To obtain proper travel times, the observed flows, hence, need to be scaled up if a down-scaled demand is used. This is done through the capacityFactor parameter in the config group. It works analogously to QSim's flow capacity factor. A factor of 0.1 performs the calculations as if the capacities were only 10% of their nominal values.

VDF Engine

The next step after imposing travel times in the QSim is to simplify simulation altogether. For this, there is the VDFEngineModule. It replaces the simulation of selected modes (like car) completely in the QSim. In particular, it removes the queue simulation as we don't need this in a VDF simulation. The agents are simply removed from the simulation at departure and added back at the destination after the trip has been finished.

There are two options to work with the generated flows:

  • Either, the engine manually generates link enter/leave events that are later tracked by the VDF module.
  • Or, we send all link traversals as a batch to the flow trackers (much more performant), but we lose the ability to analyze link enter/leave events otherwise.

By default, the VDFEngineConfigGroup is configured to generate events and replace the car mode.

Example

An example for the configuration of both cases can be found in the examples package for corsica_vdf.