Skip to Main Content
Need Support? Let’s guide you to the right answer or agent.
Status Needs review
Workspace CUBE
Created by Callum McLean
Created on May 22, 2024

Randomly distributed values of time via TOLLFACTOR on PATHLOAD.

When implementing a generalized cost form of traffic assignment and using path-based tolls in Voyager the value of time (VOT) used to convert the tolls into generalized cost is provided using the “TOLLFACTOR=” keyword on the PATHLOAD statement. Based on our testing the value of TOLLFACTOR on a given PATHLOAD statement is only evaluated once at the beginning of ILOOP phase for the first iteration and never updated again. This is a bit confusing as the “TOLLFACTOR=” keyword is defined in the documentation as an expression and generally in Voyager expressions are evaluated when called and since TOLLFACTOR is present on the PATHLOAD statement it would seem that TOLLFACTOR would be evaluated each time the PATHLOAD statement is executed (for each origin zone of the ILOOP).

The current implementation makes sense from the perspective of a fixed VOT by user class where each PATHLOAD statement represents a specific user class and the TOLLFACTOR on each PATHLOAD statement provides the VOT for the given user class. In this context one would not expect the VOT by user class to change so not revaluating the “TOLLFACTOR=” expression does not pose a problem. However, to implement an assumption of a distributed value of time when using path-based tolls, the current implementation prohibits this capability.

To work around this, we have developed a process to ‘BIN’ or ‘Bucket’ the trips for each user class by VOT based on the VOT distribution profile. Currently we are using 10 stratifications of the trip table for each user class and then assigning each of the 10 buckets on its own PATHLOAD statement and VOT by class via the TOLLFACTOR. Each of our models is a little different but for example in the Washington regional model we currently use 8 user classes that are segmented by these 10 VOT bins resulting in 80 PATHLOAD statements. In addition, we have a few miscellaneous classes that are not segmented for a total of 86 PATHLOAD statements in the assignment. The high number of PATHLOADs results in excessively long assignment run times even with the high level of IDP we can use with CLUSTER and our model servers.

When using point-based or link-based tolls, randomly distributed VOT can be computed and/or looked up and applied to the link travel times to compute link based generalized costs in the LINKREAD phase for each iteration of the assignment. Further, a LINKLOOP can be implemented in the ILOOP phase to recompute link costs for each zone thus allowing for a unique random VOT ‘draw” for each zone for each iteration. With this software enhancement we would like to be able to accomplish something similar but with path-based tolls.

If the software could be modified to re-evaluate the expression for “TOLLFACTOR=” for each zone processed in the ILOOP phase and apply this zone-specific value to the gate-to-gate tolls for the computation of the gate-to-gate generalized costs when performing zonal path building this should allow for the capability of a randomly distributed value of time assignment.

An example of how we see this being implemented in a HIGHWAY script would be something like the following:

  1. Define a LOOKUP function for precomputed randomly generated VOT based on a lookup index by origin zone and iteration

  2. Inside the ILOOP Phase compute the LOOKUP index value and look up VOTs by iteration and zone by user class

  3. Inside the ILOOP phase use a LINKLOOP to compute link based generalized costs by user class applying the current draw of the VOTs to any link-based tolls and operating costs

  4. Build generalized cost paths by user class with path-based tolls from TOLLMATI and applying current VOT (evaluated for current I zone) from TOLLFACTOR

The proposed enhancement described here is based on our understanding of how the current path-based tolling functionality works given the current implementation. Our goal is to enable some form of path-based tolling with randomly distributed values of time. If Bentley software developers have an alternative/more elegant approach to implementing something like this that would meet our needs, we would certainly be interested in discussing it with you.