-
Notifications
You must be signed in to change notification settings - Fork 0
/
03-methods.Rmd
153 lines (118 loc) · 18.8 KB
/
03-methods.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
```{r, include = FALSE}
library(targets)
library(tarchetypes)
library(tidyverse)
library(data.tree)
library(knitr)
library(kableExtra)
library(DiagrammeR)
library(ggpattern)
# Instructions and options =========
# prints missing data in tables as blank space
options(knitr.kable.NA = '')
# tells kableExtra to not load latex table packages in the chunk output
options(kableExtra.latex.load_packages = FALSE)
# options for latex-only output
if(knitr::is_latex_output()) {
knitr::opts_chunk$set(echo = FALSE, warning = FALSE, message = FALSE)
}
```
# Methods {#meth}
We developed a series of experiments to understand the relative importance of pairing an activity-based and multi-agent simulation in forecasting the uptake of ride-hailing. We performed these experiments using ActivitySim as the activity-based model and BEAM as the multi-agent simulation. We used the Salt Lake City, Utah region as a case study for our experiments. The following section outlines the methodology for which we were able to model ride-hailing ridership and level of service with differing activity-based model and multi-agent simulation mode choice combinations.
## Ride-hailing in ActivitySim
We chose ActivitySim as the activity-based model in this research because it is an open-source software with ride-hailing modal alternatives built into its framework [@rsg21]. Specifically, the ride-hail mode and the pooled ride-hail mode fall under one of the four nested tiers of ActivitySim's nested logit mode choice model. This means that ride-hail is a unique modal option not characterized by being an auto, non-motorized, or transit type mode. Figure \@ref(fig:fig-asim-nest) displays the four tiers of the nested logit mode choice model along with the modal alternatives of each tier [@mtc12]. These modal alternatives represent the alternatives available in both ActivitySim's tour based and trip based mode choice model. When determining the mode to use on a trip, ActivitySim first calculates the tour mode and subsequently calculates the trip mode based on the tour mode selection (See Figure \@ref(fig:fig-mode-compare)). Person attributes, path attributes, location attributes, tour purpose value (the main activity purpose of the tour), and more all play a role in calculating the mode choice decision.
```{r, include = FALSE}
#```{r fig-asim-nest, fig.cap = "Nested logit model used in ActivitySim.", #fig.asp=1, #fig.align='center', out.extra = 'trim = {1cm 9.5cm 4.5cm 6cm}', #fig.dim = c(6.5,9), #out.width="1.6\\linewidth", wrapfigure = list("R", .5), #echo=FALSE}
choice <- Node$new("Choice")
auto <- choice$AddChild("Auto")
drivealone <- auto$AddChild("Drive-Alone")
sharedride2 <- auto$AddChild("Share-Ride 2")
sharedride3 <- auto$AddChild("Shared-Ride 3+")
nonmotorized <- choice$AddChild("Non-Motorized")
walk <- nonmotorized$AddChild("Walk")
bike <- nonmotorized$AddChild("Bike")
transit <- choice$AddChild("Transit")
walkaccess <- transit$AddChild("Walk-Transit")
driveaccess <- transit$AddChild("Drive-Transit")
ridehail <- choice$AddChild("Ride-Hail")
taxi <- ridehail$AddChild("Taxi")
tnc_single <- ridehail$AddChild("Ride-Hail Single")
tnc_shared <- ridehail$AddChild("Ride-Hail Shared")
#print(choice)
#windowsFonts(A = windowsFont("Times New Roman"))
SetNodeStyle(choice, style = "filled,rounded", shape = "box", fontname = "A", tooltip = GetDefaultTooltip)
plot(choice)
```
\begin{figure}
\includegraphics[width = .75\paperwidth]{nestedLogit.png}
\caption{Nested logit model used in ActivitySim.}
\label{fig:fig-asim-nest}
\end{figure}
In ActivitySim, the utility $V$ for person $n \in {1:N}$ choosing alternative mode $k \in K$ between origin zone $i \in I$ and destination zone $j \in J$ is:
\begin{align}
V_{nk}^{Person} =& \ \alpha_{kn} + \beta_{kP}^1(cost_{k,ij}) + \beta_{kP}^2(age_{n})
+ \beta_{kP}^3(hhsize_{n}) (\#eq:person) \\
V_{nk}^{Path} =& \ \beta_{kP}^4(dist_{k,ij}) + \beta_{kP}^5(tv_{k,ij}) +
\beta_{kP}^6(te_{k}) + \beta_{kP}^7(tw_{k}) + \nonumber \\
& \ \beta_{kP}^8(prox_{k}) + \beta_{kP}^9(xfer_{k}) (\#eq:path) \\
V_{nk}^{Location} =& \ \beta_{kP}^{10}(ZDI_{k,i}) + \beta_{kP}^{11}(ZDI_{k,j}) +
\beta_{kP}^{12}(ZTI_{k,j}) + \nonumber \\
& \ \beta_{kP}^{13}(CBD_{k,j}) (\#eq:location)\\
V_{nk} =& \ V_{nk}^{Person} + V_{nk}^{Path} + V_{nk}^{Location} (\#eq:all)
\end{align}
where, $\alpha$ is the alternative specific constant that varies by auto sufficiency, $hhsize$ is household size, $dist$ is distance, $tv$ is vehicle travel time, $te$ is egress time, $tw$ is wait time, $prox$ is proximity to transit, $xfer$ is number of transfers, $ZDI$ is zonal density index, $ZTI$ is zonal topography index, $CBD$ is central business district, and $\beta_{P}^1:\beta_{P}^{13}$ are estimated coefficients that vary by tour purpose $P$. Equation \@ref(eq:person) shows part of the ActivitySim's mode choice utility function that focuses on person variables. Equation \@ref(eq:path) shows the part of the mode choice utility function that focuses on path variables. Equation \@ref(eq:location) shows the part of the mode choice utility function that focuses on location variables. As shown in Equation \@ref(eq:all), ActivitySim uses the combination of person, path, and location variables to calculate the mode choice alternative. The combination of these different variable types determines whether or not a person selects a ride-hailing mode. In addition, since activity-based models do not use variable wait time, the average wait time is selected before the model run.
## Configuring ActivitySim
ActivitySim requires three inputs:
1. A synthetic population of the agents within the study area.
2. A zonal socioeconomic data file describing the characteristics of each zone.
3. A set of skims that describe the cost and travel times of all modes between all zones.
We generated the synthetic population by inputting a seed table and a set of regional targets into PopulationSim [@popsim]. We created the zonal socioeconomic file using data from Wasatch Front Regional Council (WFRC) [@wfrc], Utah Automated Geographic Reference Center [@agrc], and the synthetic population when necessary. Finally we used travel time and cost skims that were pre-generated from @wfrc. For additional details relating to how the inputs were processed and gathered please refer to the research conducted by @macfarlane21.
After generating the necessary input files, we calibrated and validated the ActivitySim model to better represent decisions made in the Salt Lake region. The process of calibrating and validating the ActivitySim model to the Salt Lake region was conducted by @macfarlane21. The purpose of the calibration and validation was to ensure that the outputs generated by ActivitySim matched target regional values. Specifically, trip productions, trip distributions, and mode choices were tested to match the given target values provided in the four-step model from @wfrc. The details behind the exact calibration and validation process are discussed by @macfarlane21.
## Ride-hailing in BEAM {#novel-beam}
The Behavior, Energy, Autonomy, and Mobility (BEAM) model, developed by Lawrence Berkeley National Laboratory and UC Berkeley Institute for Transportation Studies, was chosen as the multi-agent simulation in this research [@beam]. As an extension of MATSim, it simulates individual agents using both within day replanning and across-day replanning to maximize individual utility. BEAM was mainly chosen as the multi-agent simulation in this research because of its integration with ride-hail and pooled ride-hail vehicles. Along with the ride-hailing type mode options, BEAM supports other mode options such as car, walk, bike, walk-to-transit, and drive-to-transit. The default BEAM version uses a simple multinomial logit mode model to determine which mode any particular agent will use on any particular trip. The default version of BEAM calculates the utility $V$ for person $n \in {1:N}$ choosing alternative mode $k \in K$ between origin zone $i \in I$ and destination zone $j \in J$ as:
\begin{equation}
V_{nk} = \alpha_{k} + \beta_k^1(cost_{k,ij}) + \beta_k^2(tv_{k,ij}) + \beta_k^3(xfer_{k}) (\#eq:beam)
\end{equation}
where, $\alpha$ is the alternative specific constant that varies mode, $tv$ is vehicle travel time, $xfer$ is number of transfers and $\beta_{P}^1:\beta_{P}^{3}$ are estimated coefficients that vary mode.
However, we improved the BEAM's default mode choice model in order to better estimate the ride-hailing choices of individuals. Specifically, we changed the BEAM mode choice model to use a tour purpose attribute, the same utility equations as ActivitySim (See Equation \@ref(eq:all)), and additional modal alternatives consistent with those present in ActivitySim. Appendix A provides a deeper explanation of these changes.
In addition to having a consistent mode choice structure with that of ActivitySim, BEAM implements ride-hailing vehicular behavior and assignment. BEAM uses a greedy asynchronous ride-hailing matching algorithm that also supports pooled trips [@beam]. The algorithm works by requiring agents to send a request for a ride-hail vehicle, and then by matching the closest vehicle available to that agent. For the algorithm to work, BEAM requires the modeler to input a ride-hail vehicle fleet. This fleet is a simple file that describes the number of ride-hail vehicles available in the region, their starting locations, their working hours, their seating capacity, and other specifications. Our fleet was generated by a student at Georgia Institute of Technology who used statistical models to predict fleet specifications. BEAM assigns fleet vehicles to the roadway network, where they "roam" the streets awaiting requests. The ride-hail algorithm permits a more realistic ride-hail modeling structure. For example, agents make a request to take a ride-hail vehicle, expect a variable wait time dependent on their geographic location, and may not even be able to take the vehicle if there is no availability. All these attributes are similar to how using ride-hailing is in real life, and represent the true advantages to modeling ride-hailing ridership and level of service with BEAM.
## Configuring BEAM
BEAM was configured to the case study region by gathering the input data, validating the utility parameter values, and calibrating the utility alternative specific constants (ASC) to match regional totals. Most of the BEAM input files were directly generated by the calibrated ActivitySim model, with the exception of the network from @wfrc and the General Transit Feed Specification (GTFS) data from @gtfs. The utility parameter coefficients used in BEAM's mode choice model were copied directly from Metropolitan Transportation Commission's (MTC) implementation of ActivitySim [@mtc12]. MTC's implementation of ActivitySim was designed for the San Francisco, California region. Logically, travel behaviors such as travel time, travel distance, and number of transfers should affect people in different regions in similar ways. However, as a way to validate the use of ActivitySim's path utility coefficients in the Salt Lake region, we compared these values to values from the Utah Statewide model [@utahstate], the WFRC travel demand model [@wfrc], and National Cooperative Highway Research Program (NCHRP) Report 716 [@nchrp]. The Utah Statewide model provided a rough idea of the influence of path variables in Utah as a whole. The WFRC model provided a direct comparison of travel behavior for the same region of study used in this research. NCHRP Report 716 provided default parameter values from a generalized modeling point of view. Overall, comparing these three sets of path parameter values with the MTC ActivitySim parameter values used in BEAM helped ensure that the the mode choice utility parameters were reasonable.
Figure \@ref(fig:coef) shows the comparison of the path utility parameter values between all four models for home-based work, home-based school, and home-based other trips. To view all parameters on the same scale, each value is divided by the vehicle travel time coefficient. For the egress time, vehicle travel time, the number of transfers, transfer time, and the wait times, MTC's ActivitySim has very similar coefficient ratio values as the other three models. In all these cases, the coefficient ratio is equal to or within 1 of at least one of the comparison model ratios. A large discrepancy does exist, however, with short and long walking distances. ActivitySim uses values almost 10 fold that of the other models. This occurs because the WFRC and Utah Statewide models cap walking distance whereas ActivitySim instead gives a high penalty for long walking distances. With this clarification along with knowing the other parameters fall within a close range of the other models, we decided not to calibrate the ActivitySim path coefficients and instead left them as is.
```{r coef, echo = FALSE, warning = FALSE, message = FALSE, fig.cap = "Mode choice path coefficients model comparison by tour purpose.", fig.scap="Path coefficients model comparison.", out.extra='', fig.align='center'}
tar_read(coef_graph)
```
Lastly, after completing the utility parameter validation we calibrated the mode choice utility function's alternative specific constants. The new ASC value $\alpha'$ was calculated as:
\begin{equation}
\alpha_{nk}' = \alpha_{nk} + ln(\frac{T_{nk}^{ASIM}}{T_{nk}^{BEAM}}) (\#eq:eqcalib)
\end{equation}
where $n$ is auto sufficiency, $k$ is modal alternative, $\alpha$ is the previous iteration's ASC value, $T^{ASIM}$ is ActivitySim trip shares, and $T^{BEAM}$ is BEAM trip shares. We completed the BEAM calibration through an iterative process of updating ASC values using Equation \@ref(eq:eqcalib). After completing 15 iterations of compounding Equation \@ref(eq:eqcalib) on the ASC values, the BEAM trip values were within a reasonable range to the ActivitySim target shares. Figure \@ref(fig:fig-beam-calib) shows the progress of the calibration targets with the final shares after each iteration.
```{r fig-beam-calib, fig.dim = c(6.5,8), fig.cap="BEAM mode choice calibration process. Note that the y axis grouping titles are activity types where 'Discr.' represents 'Discretionary' and 'Escort' represents dropping someone off.", fig.scap="BEAM mode choice calibration process."}
#, dev='tikz'
beam_calib <- tar_read(beam_calib)
beam_calib
```
## Case Study Scenarios {#meth-scenarios}
After completing the BEAM validation and BEAM calibration for the case study region, we designed a series of different BEAM experiments. We ran each experiment for a total of 12 iterations using a 15% population size. More specifically, we conducted nine different experiments, each with a unique ActivitySim-to-BEAM mode choice combination. Table \@ref(tab:tbexperiments) provides a short name description of the nine different scenarios.
\begin{table}
\caption[ActivitySim-to-BEAM Mode Choice Combination Names]{ActivitySim-to-BEAM Mode Choice Combination Scenario Names}
\vspace{-10mm}
\renewcommand{\arraystretch}{2}
\[
\begin{array}{cc|ccc}
&\multicolumn{1}{c}{} & \multicolumn{2}{c}{\text{ActivitySim}} \\
&& \text{Plans without ride-hail} & \text{Plans with RideHail}\\
\hline
& \text{None} & \text{} & \text{AsimRideHail} \\
\smash{\rotatebox[origin=c]{90}{\text{BEAM}}} & \text{RideHail} & \makecell{\text{BeamRideHail:Path} \\ \text{BeamRideHail:PPL}} & \makecell{\text{AsimBeamRideHail:Path} \\ \text{AsimBeamRideHail:PPL}} \\
& \text{All} & \makecell{\text{BeamAll:Path} \\ \text{BeamAll:PPL}} & \makecell{\text{AsimBeamAll:Path} \\ \text{AsimBeamAll:PPL}}
\end{array}
\]
\label{tab:tbexperiments}
\vspace{-5mm}
\end{table}
To better describe the meaning of each scenario in Table \@ref(tab:tbexperiments), we explain the three mode choice descriptors that were altered in each scenario. The first descriptor refers to how ActivitySim's modes were configured, which in Table \@ref(tab:tbexperiments) is labeled under *ActivitySim* as *Plans without RideHail* and *Plans with RideHail*. In the naming convention, any name starting with *Asim* refers to any scenario where ride-hailing was included in the input plans from ActivitySim, and any name without *Asim* refers to any a scenario where ride-haling was excluded from the inputs plans from ActivitySim. In other words, the ActivitySim ride-hailing nesting option as shown in Figure \@ref(fig:fig-asim-nest) only existed in one version of ActivitySim. Since the daily activity plans generated by ActivitySim were converted to BEAM inputs, this descriptor explains the initial mode choice selections for all trips entered into BEAM.
The second descriptor present in Table \@ref(tab:tbexperiments) is labeled under *BEAM* as *None*, *RideHail*, and *All*. These three variables explain which mode choice structure was used in BEAM. These variables also explain which modal alternatives were available for choice within BEAM. The *None* category represents a version of BEAM where all modal innovation was turned off. This means that no mode choice was available and agents did not select to choose alternate modes. The *RideHail* category represented a version of BEAM where modal innovation was partially turned off. All trips that originally took car or carpool modes had modal innovation turned off; their modes were locked. All trips that originally took walk-transit or drive-transit modes, however, were given the option to switch to a ride-haliing mode. Also, all walk modes were given the option to switch to a ride-hail vehicle. *RideHail* represents the version of BEAM where ride-hail and ride-hail transit modes were only given to none-car dependent agents. Finally, the *All* category represents a version of BEAM where modal innovation was turned on, and all modal alternatives were available for choice. This means that within-day replanning as well as across-day replanning was turned on, and agents could change their trip modes to maximize their utility.
Finally, the third descriptor present in Table \@ref(tab:tbexperiments) is labeled as either *Path* or *PPL* and explains which utility variables were used to calculate modal utility. The *Path* option represented the version of BEAM that used Equation \@ref(eq:path), which used only path type utility parameters to calculate mode choice utility. The *PPL* option represented the version of BEAM that used Equation \@ref(eq:all), which used all path, person, and location type utility parameters to calculate mode choice utility.
## Summary
Overall, we ran nine different scenarios each with a slightly different ActivitySim-to-BEAM mode choice combination. Each scenario is built from which modes were included in the input plans, which modal alternatives were available for choice, and which utility parameter types were used to calculate the mode choice utility. By altering these three different mode choice characteristics, we hope to better understand the affect different linked activity-based model and multi-agent simulation combinations have on ride-hailing ridership and level of service.