Fixed Demand#
The main motivation behind using a fixed demand is to ensure scenarios can be compared with minimal variability arising from demand fluctuations. For a particular trip request in this context, request IDs can be maintained between scenarios that can help compare how that trip is routed with and without dynamic ride-sharing, for example. There are a few important considerations to operationalize a fixed demand run for shared mobility analysis.
Maintaining network state from other sources of demand#
To maintain network congestion patterns arising as a result of all other modes using the network, a fixed set of trips made by travelers other than when using the shared mobility models should be incorporated in the input Demand database. These trips are routed from their origin to their destination, at the set departure/start time with routes changing based on network states. These trips, added to the Trip table, are of the fixed trip type, external to the simulation components and are tagged with the type set to 22 (representing External).
Input scenario file parameters allows you to control what percent of the input you want to sample.
"read_trip_factors": { "External": 0.25},
Fixed demand dynamic traffic assignment (DTA) with on-demand routing#
The previous two sections covered how input demand is created, with the appropriate types, and how different proportions can be read into the simulation. A series of dynamic traffic assignment iterations can then be run with POLARIS to obtain a stable network state. This involves all external demand finding their best routes, and storing paths to fix navigation based on their lowest experienced travel time. Demand through the shared mobility module layers on top reacting to on-demand requests (although fixed) generating routing and assignment within the fleet of shared vehicles. Feedback mechanisms for the shared mobility module, such as maintaining initial vehicle location states, memory of zonal revenue and wait times, helps the operator improve operations. When using polaris-studio, fixed demand assembled by following the previous sections can be run by using the following parameters in the convergence_control.yaml file:
db_name: "Grid"
do_skim: False
do_abm_init: False
num_threads: 4
num_abm_runs: 0
num_dta_runs: 5
The primary motivation behind fixing demand (trips made by the population) is to evaluate the performance of policy or technological changes. A downside is that some of these changes impact decisions made by agents (e.g., mode choice, destination choice, timing choice), and thus locking in demand may not show total change. Dropping all paths in this demand database ensures that POLARIS reroutes paths and helps with DTA convergence.
For a more detailed understanding of how the POLARIS dynamic traffic assignment module works, please refer to the Assignment section.