Exploring Complexity and Complicatedness in Travel Demand Modeling Systems

undefined
 
GTAModel V5
Workshop
 
September 20, 2023
 
1
 
Agenda
 
Some basic principles.
Overall model structure.
TASHA core.
Network modelling.
Population & employment synthesis.
Mid/long-term mobility decisions.
Daily activity/travel demand.
Other issues.
Staff/schedule.
 
2
 
GTAModel V4
 
GTAModel V4 is now in operational use, or in the process of being
implemented in:
Almost all GTHA agencies.
Region of Niagara.
ARTM, Montreal.
JRTA, Halifax.
Monterrey, Mexico.
Research-based transfers have also occurred in:
Changzhou, China (Southeastern University).
London, UK (Imperial College).
Melbourne, Australia (Monash University).
Sydney, Australia (UNSW).
Temuco, Chile (University of Concepcion).
Asuncion, Paraguay (UofT TMG).
Cape Town, South Africa (UofT TMG).
Latest version, V4.2, is being applied to a project for the TTC.
 
3
 
GTAModel V5
 
While we will continue to support operational V4 implementations
and incremental upgrades, we want the next release to be a
significant upgrade to a Version 5 of the model system that:
Builds upon and incorporates all the “lessons learned” with V4.
Is able to deal with the post-pandemic “new normal”.
Hybrid work environment.
In-home/virtual activity participation.
New mobility systems.
Is:
Behaviourally sound.
Policy-sensitive.
Computationally efficient.
Easy to use.
Flexible & extensible to support continuing evolution.
 
4
 
Basic Principles
 
Activity- & agent-based microsimulation.
Complexity vs. complicatedness.
Overall model system structure.
The TASHA core.
 
5
 
 
Complexity vs. Complicatedness (1)
 
From a complex systems perspective, “complexity” refers to 
behaviour.
Complex behaviour arises from various combinations of:
Dynamic feedback.
Stochastic effects.
Uncertainty.
Complicated structure.
Complicatedness refers to the intricacy of system 
structure
.
Travel behaviour and transportation system performance are both
behaviourally complex and structurally complicated.
 
6
 
Complexity & Complicatedness (2)
 
Regional travel demand model systems are examples of 
aggregate
complexity
 systems.
Their many components & sub-components make understanding how the
system works and what the model outputs will be given inputs difficult.
A major challenge in model system design is to keep the system as
simple as possible (minimize complicatedness) while maximizing its
ability to generate behavioural complexity.
I would argue that most commercial model systems are overly
complicated and insufficiently behaviourally complex.
To reverse this situation, requires both:
Strong, parsimonious theory.
Careful software design.
 
7
 
Complexity & Complicatedness (3)
 
An important strategy for effective complex
systems modelling is hierarchical modularity,
combined with encapsulation.
Hierarchical modularity: Break the system
down into well defined modules.
Hierarchically related.
Keep logically separate processes separate:
don’t overload any single module.
Well defined interfaces.
Encapsulation:
The workings within each module are self-
contained and don’t depend on other
modules.
Interaction between modules is only
through their interfaces (inputs & outputs).
Applies to both theoretical specifications &
programming implementation.
Arguably most existing software (including,
occasionally our own!) is overly “monolithic”,
making model evolution difficult or even
impossible.
 
8
 
Overall Model System Structure (1)
 
All so-called activity-based model systems have the same overall model system
structure.
What differs is:
Boundaries between major boxes.
What “goes inside the box”.
 
9
 
Overall Model System Structure (2)
 
Static, “one-step” forecast for a future year.
Requires exogenous forecast of total population and
employment by TAZ for the forecast year.
Individual agents (persons and, possibly,
households) are “statistically” synthesized with
individual attributes.
How is employment handled?
Three major “behavioural” components:
Mid/long-term decisions that condition daily
activity & travel.
Modelling “typical” (“average”) weekday demand
for activity & travel.
Assigning trips by mode to the transportation
network.
Determines modal LOS by link & O-Ds.
Route (path) choice equilibrium assumed given input
O-Ds.
Equilibrium is imposed between travel demand and
network LOS.
 
10
Population Synthesis
Mid/Long-Term Decisions
Daily Activity/Travel Demand
Network Assignment
TAZ Pop & Emp Forecast
Network Scenario
Equilibrium
?
Output Results
 
Yes
 
No
 
This overall model structure will be retained in V5.
 
Overall Model System Structure (3)
 
Note that the upper 3 boxes are the static
replacement for a dynamic, evolutionary
integrated land use – transport model
system.
 
11
Demographic Update
Labour Force (PoRPoW) Update
School Participation Update
Daily Activity/Travel Demand
Network Assignment
Base Year Persons, Jobs, etc.
Network Scenario
T =
Forecast
Year?
Output Results
 
Yes
 
No
T = 0
T = T+1
Employment Update
Mobility Tool Update
 
We are NOT proposing an ILUTE-like model system for V5!
But, we want our V5 models to be, as much as possible, “static
placeholders” for an eventually more dynamic system.
 
The TASHA Core
 
Generally, the greatest difference among model systems is
how they model daily activity/travel demand.
In GTAModel, we use TASHA (Travel/Activity Scheduler for
Household Agents).
TASHA is a true activity scheduling procedure, which
generates out-of-home activity episodes for each person &
household for the simulated day.
It is explicitly household-based.
It works in continuous time over a 24-hour weekday time
period.
A distinguishing feature of TASHA is that it is project-based:
activity episodes are generated within projects to achieve
project goals.
The basic structure of TASHA will be retained in V5, but a
number of improvements will be introduced in model
specifications & interactions.
 
12
 
For every household h:
Generate household h activity episodes
 
For each person p in household h:
Generate person p individual episodes (including
locations for NWS episodes)
Schedule person p’s individual & household
episodes & trips
Tour-based mode choice for person p
Assign household cars to drivers
Assign drivers & passengers to intra-household rideshare
trips
PDF
Activity
Frequency
Activity
Frequency
Joint
PDF
Start
Time
Feasible
Start Times
Start
Time
Joint
PDF
Duration
Feasible
Durations
(a) Draw activity
frequency from
marginal PDF
(b) Draw activity start
time 
from
 feasible
region in joint PDF
(c) Draw activity
Duration from
feasible region in
joint PDF
Activity Episode Frequency, Start Time and Duration Generation
             At – Home
Work
Work
Shop 1
Shop 2
Other
Other
Work Project
School Project
Other Project
Shopping Project
Shop 1
At-home
Other
Shop 2
Person 
Schedule
= “Gap” in Project Agenda
= Activity Episode
= Travel Episode
At-home
At-home
:
:
Scheduling Activity Episodes into a Daily Schedule
TASHA generates the number of activity
episodes from a set of “projects” that a
person (or household) might engage in
during a typical weekday.  It also generates
the desired start time and duration of each
episode.
It then builds each person’s daily schedule,
adjusting start times and durations to ensure
feasibility.
Travel episodes are inserted as part of the
scheduling process.
Activity Generation & Scheduling in
TASHA
 
Tour-Based Mode Choice 
(Multinomial Probit Model)
 
Structure of the TASHA TBMC will be unchanged in V5.
Representation of ridehailing mode, among others will be improved.
 
Chain c:
1. Home-Work
2. Work-Lunch
3. Lunch-Meeting
4. Meeting-Work
5. Work-Home
 
m1 = drive
 
Sub-Chain s:
2. Work-Lunch
3. Lunch-Meeting
4. Meeting-Work
 
 
 
 
 
m2
 
m3
 
m4
 
 
Non-drive for
    Sub-chain s
 
m2 = drive
m3 = drive
m4 = drive
 
 
Drive for
Sub-chain s
 
m5 = drive
 
Drive Option for Chain c
 
mN = mode chosen for trip N
 
TASHA’s tour-based mode choice model:
 Handles arbitrarily complex tours and sub-tours without needing to pre-
specify the tours.
 Dynamically determines feasible combinations of modes available to use
on tours. Modes can be added without changing the model structure.
 Cars automatically are used on all trips of a drive tour.
 
Network Assignment (1)
 
We have always used Emme as our network modelling software for road &
transit assignment (since 1988!).
Recently, interfaces to Aimsun & Visum have been developed.
V5: We continue to use Emme as our standard network modelling software, with
extensions to Aimsun & Visum as needed.
STATIC EQUILIBRIUM ASSIGNMENT! 
(aka Deterministic User Equilibrium, DUE)
Computationally efficient.
Multi-decade experience/investment within the region.
“OK” for many/most longer-range, strategic planning purposes.
We recognize that some agencies are experimenting with DTA (Aimsun-
mesoscopic; Dynameq). We are also interested in MATSim.
DTA vs. DUE is actually not critical to V5 design.
Is largely a computational issue, although other issues exist:
Future year data inputs.
Precision needed for strategic planning.
Arguably a more micro/dynamic representation of transit is often more needed than road DTA.
Continuing discussion & research is required, but can proceed in parallel to V5.0
development.
 
16
 
Network Assignment (2)
 
The ARTM implementation involves
implementation of Emme’s Space-Time Traffic
Assignment (STTA) algorithm for doing one-hour
road assignments that provide a “quasi-
dynamic” modeling of traffic flow.
Arguably a nice “compromise” between
conventional static & dynamic assignment
procedures.
We have developed a somewhat equivalent
module for doing one-hour transit assignments.
This replaces the V4 assignments of
“representative” single-hour assignments per
time period.
This is computationally more intensive, but
should yield improved representation of modal
LOS over time over the day.
If works well, will be adopted in V5.
 
17
undefined
 
Population &
Employment
Synthesis
 
 
18
 
Population Synthesis (1)
 
Population synthesis is a relatively well understood problem.
Various implementations of V4 use different population synthesizers:
Simple cloning fi TTS records.
PopSyn3 (WSP product).
MetroPop (developed by Metrolinx).
Other options include:
PopulationSim: Updated version of PopSyn3. Open source, much more
computationally efficient.
New custom package.
G5 should be able to interface with any synthesizer that meets its
design specs:
Generates a list of synthetic persons with attributes required by TASHA.
Each person is attached to a synthetic household with attributes required by
TASHA.
On the other hand, it would be good to have a population synthesizer
that is readily transportable to other urban areas.
 
19
 
Population Synthesis (2): MetroPop
 
Travel Modelling Group
 
The default option for G5 is MetroPop.
Sophisticated synthesizer.
Fine-tuned for GGH.
However:
Data intensive.
Highly “integrated”.
I would like to investigate a simpler, more modular, easier to use approach.
So, we’ll see!
 
Population Synthesis (3)
 
Ideally, I would like to clearly differentiate between
demographic synthesis (age, gender, etc.) and economic
attributes (labour force participation, income, etc.)
.
Keep it simple, efficient, “statistical”.
Push all “decisions” into explicit, subsequent modules.
Easy to change parameters, models.
Potentially policy sensitive.
Also “behaviourally sound”.
Aside from MetroPop, V4 synthesis has always been
based on TTS data.
Probably a much more census-based approach should be
adopted.
Similar to GGH Model.
 
21
 
Population Synthesis (4):
Person Attributes
 
Minimum required:
Age.
Gender (male, female).
Ethnicity.
1
Recent immigrant (yes/no).
1
Possibly?
Education level.
2
 
1.
Not in V4. Will be supported by TTS 2022. Increasingly
required for policy analysis. May or may not enter demand
models.
2.
Might be useful for determining labour force participation,
occupation, etc.
 
22
 
Population Synthesis (5):
Household Attributes
 
Minimum required:
Number of persons.
Household type (single person, family w/o children, family w/
children, non-family, …?).
 
The household is largely a “container” of persons (but it is an
important agent in TASHA).
Most household attributes are generated in subsequent modules.
 
23
 
Employment (Job) Synthesis
 
Job synthesis is largely ignored (or at least not discussed) in many
model systems.
Generally individual jobs need be synthesized, but total employment
per TAZ most be disaggregated into by occupation & employment status
(full/part-time) for assignment to workers.
In V4, this is done by simply applying observed base year (TTS) rates.
This could be replaced by base year Census rates if we go to a more Census-
based model.
In forecasting, these rates could be replaced by assumed future year
scenario rates. It is our impression that this is rarely, if ever done.
At this time, we are not proposing to do anything different for V5.
But, happy to discuss options.
I am including this module here under “synthesis” (as opposed to
“labour market modelling”, see upcoming slides), but this could be
debated.
 
24
undefined
 
Mid/Long-Term
Mobility Decisions
 
 
25
 
Mid/Long-Term Mobility Decisions
 
Labour market:
Labour force participation.
1
WaH.
1
PoRPoW.
Income.
1
Education:
Student status.
1
PoRPoS.
Mobility tools:
Driver’s license.
Household auto ownership.
Mobility memberships (carshare? Bikeshare? …)
2
 
26
 
1.
Currently in population synthesis.
2.
Not currently in GTAModel.
 
Labour Market Participation
 
Assign to each person 16+ years old:
Employment status:
Full-time employed.
Part-time employed.
Not employed.
Occupation category, given empstat.
Note: new occupations in TTS 2022!
Currently part of population synthesis. Move it out into
its own module.
 
27
 
Work at Home (WaH) (1)
 
A major issue in post-pandemic travel modelling is dealing with the new hybrid
work environment.
Key definitions required to begin to address this issue:
Work at Home (WaH): The worker does 
not
 have an out-of-home workplace.
Self-employed.
Employed by a company but:
Has no office – working all the time from home.
May nominally have an office but never uses it.
1
Work from Home (WfH): The worker has a place of employment outside the home,
but on the simulated day s/he works from home and does not commute to the
workplace.
This terminology hopefully helps clarify different behaviours and is arguably
better than the traditional term “telecommuting”, which does not (usually)
differentiate well between the two options.
 
28
 
1. This may be better included in WfH with zero days commuting to the workplace?
 
WaH (2)
 
WaH logically belongs within the mid/long term labour market
component of the model system, since it does not change on a day-
to-day basis.
WaH has always been included in the GTAModel model systems, but,
without adequate differentiation from WfH.
V4:
Part of population synthesis.
Simple rates.
V5:
Pull out as a separate module to facilitate model upgrades and scenario
testing.
Keep rate-based model. Investigate improving categorization.
 
29
 
Place of Residence – Place of
Work (PoRPoW)
 
Assigns specific workplaces (TAZ) to each worker based
on worker employment status & occupation.
V5: Keep the basic V4 approach (doubly-constrained
entropy/gravity model).
Can the explanatory variables be improved?
Income?
Inclusion of external jobs/workers within the model.
Enhanced spatial structure effects:
Central Place Theory concepts.
Regional structure.
 
30
 
Auto Ownership
 
EVs.
Much work going on in this area; will incorporate.
Have a PhD student working on this (Mwendwa Kiko).
AVs:
Not in V5.0.
Privately-owned Avs represent a major change in
activity/travel modelling.
AV-based ridesharing is “easy” to handle if we have
implemented the ridehailing model.
 
31
undefined
 
Daily
Activity/Travel
Demand:
TASHA2
 
 
32
 
Key Issues to Address in TASHA2
 
1.
Improved “feedback” between TASHA modules.
2.
Incorporating new mobility services.
3.
Modelling WfH/hybrid work.
4.
Many others:
1.
Virtual/in-home activities.
2.
Modelling spatial choice.
3.
Active transportation.
 
33
 
Feedback within TASHA
 
The current TASHA activity episode generation & scheduling
components are very sequential in design, with little
feedback. As a result:
Activity episode generation is quite inelastic.
Some inconsistencies between calculations in different
modules can occur.
More interactions between generation, scheduling, mode
choice and NWS location choice are required.
Also need to deal better with:
Supervision, etc. of dependents (e.g., children).
WfH effects.
These are the oldest parts of the software & have not been
touched in a long while.
In V5 we will “open up the box” to improve these
interactions & update the code.
Will need to experiment with alternative structures.
Iteration within TASHA.
Gibbs Sampling?
 
34
 
Incorporating Mobility Services
 
PhD student Shuoyan Xu will be implementing a model of ridehailing
service/performance in V5, based on Francisco Calderón’s prototype.
We have access to City of Toronto VfH data to support this work (plus TTS &
THATS data).
Tour-based mode choice model will be updated accordingly.
 
35
 
WfH
 
Major challenge!
It is far from clear that we can continue modelling a single
“typical day”. Do we need a multi-day model? Options
include:
Run 5 one-day models.
Experimenting with week-long model.
THATS survey will support both options.
Feedback effects of WfH on:
Activity generation?
Auto ownership?
PhD student Mohammad Haghighi is working on week-long
modelling and can help with this work.
 
36
undefined
 
Other Issues
 
 
37
 
Expansion to the GGH!
 
GTAModel has always been focused on the GTHA, with the remainder of
the GGH being treated in a very aggregate, non-agent-based way as
“external” zones.
Although a version of the model has now been extended to the Region of
Niagara.
It would be good to extend V5 to cover the entire GGH.
This, however, will be a “heavy lift” for the small TMG staff, at least in
the short run.
Perhaps we can “second” regional agency staff to help us with some of the
data assembly, model testing, etc.?
If we do take on the whole GGH, I want to explore some sort of
“hierarchical” treatment of regions within the overall study area:
E.g., Niagara, Waterloo, etc., while connected with the GTHA are also
economic regions in their own right, with their own spatial-socio-economic
structure.
 
38
 
Time-Series Analysis
 
Pre-pandemic, the intent had been to use multiple TTS
years to develop model parameters that were “robust”
over time.
The pandemic & its aftermath have called this approach
into question.
Instead, we will develop V5 based on 2022/23 data and
compare parameters, etc. with V4.
We will also run V4 on 2022/23 data to see where the
key differences are.
Have an undergrad student doing her 4
th
 Year thesis on
this (Grace Zhang).
 
39
 
Staff
 
James Vaughan:
Lead software designer & programmer.
Model estimation & model system calibration lead.
Jeff Mukuka:
Network coding & assignment model estimation/calibration.
General analysis assistance.
Henry Waterhouse:
General analysis assistance.
Amit Sandhel:
XTMF Programming.
Postdoctoral Fellows, Ya Gao, Alex Dong, Usman Ahmad:
Data preparation.
Model estimation & testing.
Graduate Students:
Mohammad Haghighi: TASHA updates; 5-day modelling.
Mwendwa Kiko: Auto ownership modelling.
Shuoyan Xu: Ridehailing model.
Undergraduate student (Grace Zhang):
Comparison of pre- & post-pandemic travel behaviour.
 
40
 
Schedule
 
Work will begin in earnest in November.
Hopefully TTS 2022 data will be available.
TMG staff will have “some cycles to spare” for this work
by then.
Postdocs will be on staff by then.
And then we’ll see how far we can get by the end of
March.
We have always expected this work to go into the 2024-25
work year.
Will provide an update on progress and the work plan at
the Dec. 6 workshop.
 
41
 
Questions? Further discussion?
 
42
Slide Note
Embed
Share

Delve into the intricate world of travel demand modeling systems, where complexity arises from dynamic feedback, stochastic effects, uncertainty, and system structure. Discover the balance needed to minimize complicatedness while maximizing behavioral complexity in regional travel modeling. Uncover the importance of strong theoretical frameworks and thoughtful software design in creating effective model systems.


Uploaded on Apr 03, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. GTAModel V5 Workshop September 20, 2023 1

  2. Agenda Some basic principles. Overall model structure. TASHA core. Network modelling. Population & employment synthesis. Mid/long-term mobility decisions. Daily activity/travel demand. Other issues. Staff/schedule. 2

  3. GTAModel V4 GTAModel V4 is now in operational use, or in the process of being implemented in: Almost all GTHA agencies. Region of Niagara. ARTM, Montreal. JRTA, Halifax. Monterrey, Mexico. Research-based transfers have also occurred in: Changzhou, China (Southeastern University). London, UK (Imperial College). Melbourne, Australia (Monash University). Sydney, Australia (UNSW). Temuco, Chile (University of Concepcion). Asuncion, Paraguay (UofT TMG). Cape Town, South Africa (UofT TMG). Latest version, V4.2, is being applied to a project for the TTC. 3

  4. GTAModel V5 While we will continue to support operational V4 implementations and incremental upgrades, we want the next release to be a significant upgrade to a Version 5 of the model system that: Builds upon and incorporates all the lessons learned with V4. Is able to deal with the post-pandemic new normal . Hybrid work environment. In-home/virtual activity participation. New mobility systems. Is: Behaviourally sound. Policy-sensitive. Computationally efficient. Easy to use. Flexible & extensible to support continuing evolution. 4

  5. Basic Principles Activity- & agent-based microsimulation. Complexity vs. complicatedness. Overall model system structure. The TASHA core. 5

  6. Complexity vs. Complicatedness (1) From a complex systems perspective, complexity refers to behaviour. Complex behaviour arises from various combinations of: Dynamic feedback. Stochastic effects. Uncertainty. Complicated structure. Complicatedness refers to the intricacy of system structure. Travel behaviour and transportation system performance are both behaviourally complex and structurally complicated. 6

  7. Complexity & Complicatedness (2) Regional travel demand model systems are examples of aggregate complexity systems. Their many components & sub-components make understanding how the system works and what the model outputs will be given inputs difficult. A major challenge in model system design is to keep the system as simple as possible (minimize complicatedness) while maximizing its ability to generate behavioural complexity. I would argue that most commercial model systems are overly complicated and insufficiently behaviourally complex. To reverse this situation, requires both: Strong, parsimonious theory. Careful software design. 7

  8. Complexity & Complicatedness (3) Initial Network Assignment An important strategy for effective complex systems modelling is hierarchical modularity, combined with encapsulation. Hierarchical modularity: Break the system down into well defined modules. Load LoS Data Compute Access Station Models Compute Aggregate PoRPoW Compute Aggregate PoRPoS Hierarchically related. Keep logically separate processes separate: don t overload any single module. Load Household Well defined interfaces. Encapsulation: Assign Work/School Zones Assign Driver Licenses Assign Cars to Household The workings within each module are self- contained and don t depend on other modules. TASHA Interaction between modules is only through their interfaces (inputs & outputs). Applies to both theoretical specifications & programming implementation. Arguably most existing software (including, occasionally our own!) is overly monolithic , making model evolution difficult or even impossible. Mode Choice External Model Network Assignment Airport Model Compute Next Iteration Freight Model 8

  9. Overall Model System Structure (1) All so-called activity-based model systems have the same overall model system structure. What differs is: Boundaries between major boxes. What goes inside the box . TAZ Pop & Emp Forecast Population Synthesis Mid/Long-Term Decisions Network Scenario Daily Activity/Travel Demand Network Assignment No Yes Equilibrium ? Output Results 9

  10. Overall Model System Structure (2) Static, one-step forecast for a future year. Requires exogenous forecast of total population and employment by TAZ for the forecast year. Individual agents (persons and, possibly, households) are statistically synthesized with individual attributes. TAZ Pop & Emp Forecast Population Synthesis How is employment handled? Three major behavioural components: Mid/Long-Term Decisions Network Scenario Daily Activity/Travel Demand Mid/long-term decisions that condition daily activity & travel. Network Assignment Modelling typical ( average ) weekday demand for activity & travel. Yes No Assigning trips by mode to the transportation network. Equilibrium ? Output Results Determines modal LOS by link & O-Ds. Route (path) choice equilibrium assumed given input O-Ds. Equilibrium is imposed between travel demand and network LOS. 10 This overall model structure will be retained in V5.

  11. Overall Model System Structure (3) T = 0 TAZ Pop & Emp Forecast Base Year Persons, Jobs, etc. Population Synthesis T = T+1 Mid/Long-Term Decisions Demographic Update Network Scenario Daily Activity/Travel Demand Employment Update Network Assignment Labour Force (PoRPoW) Update School Participation Update Network Scenario Yes No Equilibrium ? Output Results Mobility Tool Update Daily Activity/Travel Demand Note that the upper 3 boxes are the static replacement for a dynamic, evolutionary integrated land use transport model system. Network Assignment Yes No T = Output Results Forecast Year? We are NOT proposing an ILUTE-like model system for V5! But, we want our V5 models to be, as much as possible, static placeholders for an eventually more dynamic system. 11

  12. The TASHA Core Generally, the greatest difference among model systems is how they model daily activity/travel demand. In GTAModel, we use TASHA (Travel/Activity Scheduler for Household Agents). TASHA is a true activity scheduling procedure, which generates out-of-home activity episodes for each person & household for the simulated day. It is explicitly household-based. It works in continuous time over a 24-hour weekday time period. A distinguishing feature of TASHA is that it is project-based: activity episodes are generated within projects to achieve project goals. The basic structure of TASHA will be retained in V5, but a number of improvements will be introduced in model specifications & interactions. 12

  13. For every household h: Generate household h activity episodes For each person p in household h: Generate person p individual episodes (including locations for NWS episodes) Schedule person p s individual & household episodes & trips Tour-based mode choice for person p Assign household cars to drivers Assign drivers & passengers to intra-household rideshare trips

  14. Activity Generation & Scheduling in TASHA TASHA generates the number of activity episodes from a set of projects that a person (or household) might engage in during a typical weekday. It also generates the desired start time and duration of each episode. It then builds each person s daily schedule, adjusting start times and durations to ensure feasibility. Travel episodes are inserted as part of the scheduling process. Activity Episode Frequency, Start Time and Duration Generation (c) Draw activity Duration from feasible region in joint PDF (a) Draw activity frequency from marginal PDF (b) Draw activity start time from feasible region in joint PDF Joint PDF Joint PDF Activity Frequency Start Time PDF Start Time Duration Activity Frequency Feasible Start Times Feasible Durations Scheduling Activity Episodes into a Daily Schedule Work Project Work School Project Other Project Other Shopping Project : : Shop 1 Shop 2 Person Schedule At-home Work At Home Other Shop 1 Other At-home Shop 2 At-home = Travel Episode = Activity Episode = Gap in Project Agenda

  15. Tour-Based Mode Choice (Multinomial Probit Model) Structure of the TASHA TBMC will be unchanged in V5. Representation of ridehailing mode, among others will be improved. Chain c: 1. Home-Work 2. Work-Lunch 3. Lunch-Meeting 4. Meeting-Work 5. Work-Home mN = mode chosen for trip N Drive Option for Chain c Non-drive options for Chain c m1 = drive Sub-Chain s: 2. Work-Lunch 3. Lunch-Meeting 4. Meeting-Work m5 m4 m3 m2 m1 Drive for Sub-chain s Non-drive for Sub-chain s TASHA s tour-based mode choice model: Handles arbitrarily complex tours and sub-tours without needing to pre- specify the tours. Dynamically determines feasible combinations of modes available to use on tours. Modes can be added without changing the model structure. Cars automatically are used on all trips of a drive tour. m2 = drive m3 = drive m4 = drive m4 m3 m2 m5 = drive

  16. Network Assignment (1) We have always used Emme as our network modelling software for road & transit assignment (since 1988!). Recently, interfaces to Aimsun & Visum have been developed. V5: We continue to use Emme as our standard network modelling software, with extensions to Aimsun & Visum as needed. STATIC EQUILIBRIUM ASSIGNMENT! (aka Deterministic User Equilibrium, DUE) Computationally efficient. Multi-decade experience/investment within the region. OK for many/most longer-range, strategic planning purposes. We recognize that some agencies are experimenting with DTA (Aimsun- mesoscopic; Dynameq). We are also interested in MATSim. DTA vs. DUE is actually not critical to V5 design. Is largely a computational issue, although other issues exist: Future year data inputs. Precision needed for strategic planning. Arguably a more micro/dynamic representation of transit is often more needed than road DTA. Continuing discussion & research is required, but can proceed in parallel to V5.0 development. 16

  17. Network Assignment (2) The ARTM implementation involves implementation of Emme s Space-Time Traffic Assignment (STTA) algorithm for doing one-hour road assignments that provide a quasi- dynamic modeling of traffic flow. Arguably a nice compromise between conventional static & dynamic assignment procedures. We have developed a somewhat equivalent module for doing one-hour transit assignments. This replaces the V4 assignments of representative single-hour assignments per time period. This is computationally more intensive, but should yield improved representation of modal LOS over time over the day. If works well, will be adopted in V5. 17

  18. Population & Employment Synthesis 18

  19. Population Synthesis (1) Population synthesis is a relatively well understood problem. Various implementations of V4 use different population synthesizers: Simple cloning fi TTS records. PopSyn3 (WSP product). MetroPop (developed by Metrolinx). Other options include: PopulationSim: Updated version of PopSyn3. Open source, much more computationally efficient. New custom package. G5 should be able to interface with any synthesizer that meets its design specs: Generates a list of synthetic persons with attributes required by TASHA. Each person is attached to a synthetic household with attributes required by TASHA. On the other hand, it would be good to have a population synthesizer that is readily transportable to other urban areas. 19

  20. Population Synthesis (2): MetroPop The default option for G5 is MetroPop. Sophisticated synthesizer. Fine-tuned for GGH. However: Data intensive. Highly integrated . I would like to investigate a simpler, more modular, easier to use approach. So, we ll see! Travel Modelling Group

  21. Population Synthesis (3) Ideally, I would like to clearly differentiate between demographic synthesis (age, gender, etc.) and economic attributes (labour force participation, income, etc.). Keep it simple, efficient, statistical . Push all decisions into explicit, subsequent modules. Easy to change parameters, models. Potentially policy sensitive. Also behaviourally sound . Aside from MetroPop, V4 synthesis has always been based on TTS data. Probably a much more census-based approach should be adopted. Similar to GGH Model. 21

  22. Population Synthesis (4): Person Attributes Minimum required: Age. Gender (male, female). Ethnicity.1 Recent immigrant (yes/no).1 Possibly? Education level.2 1. Not in V4. Will be supported by TTS 2022. Increasingly required for policy analysis. May or may not enter demand models. 2. Might be useful for determining labour force participation, occupation, etc. 22

  23. Population Synthesis (5): Household Attributes Minimum required: Number of persons. Household type (single person, family w/o children, family w/ children, non-family, ?). The household is largely a container of persons (but it is an important agent in TASHA). Most household attributes are generated in subsequent modules. 23

  24. Employment (Job) Synthesis Job synthesis is largely ignored (or at least not discussed) in many model systems. Generally individual jobs need be synthesized, but total employment per TAZ most be disaggregated into by occupation & employment status (full/part-time) for assignment to workers. In V4, this is done by simply applying observed base year (TTS) rates. This could be replaced by base year Census rates if we go to a more Census- based model. In forecasting, these rates could be replaced by assumed future year scenario rates. It is our impression that this is rarely, if ever done. At this time, we are not proposing to do anything different for V5. But, happy to discuss options. I am including this module here under synthesis (as opposed to labour market modelling , see upcoming slides), but this could be debated. 24

  25. Mid/Long-Term Mobility Decisions 25

  26. Mid/Long-Term Mobility Decisions Labour market: Labour force participation.1 WaH.1 PoRPoW. Income.1 Education: Student status.1 PoRPoS. Mobility tools: Driver s license. Household auto ownership. Mobility memberships (carshare? Bikeshare? )2 1. Currently in population synthesis. 2. Not currently in GTAModel. 26

  27. Labour Market Participation Assign to each person 16+ years old: Employment status: Full-time employed. Part-time employed. Not employed. Occupation category, given empstat. Note: new occupations in TTS 2022! Currently part of population synthesis. Move it out into its own module. 27

  28. Work at Home (WaH) (1) A major issue in post-pandemic travel modelling is dealing with the new hybrid work environment. Key definitions required to begin to address this issue: Work at Home (WaH): The worker does not have an out-of-home workplace. Self-employed. Employed by a company but: Has no office working all the time from home. May nominally have an office but never uses it.1 Work from Home (WfH): The worker has a place of employment outside the home, but on the simulated day s/he works from home and does not commute to the workplace. This terminology hopefully helps clarify different behaviours and is arguably better than the traditional term telecommuting , which does not (usually) differentiate well between the two options. 1. This may be better included in WfH with zero days commuting to the workplace? 28

  29. WaH (2) WaH logically belongs within the mid/long term labour market component of the model system, since it does not change on a day- to-day basis. WaH has always been included in the GTAModel model systems, but, without adequate differentiation from WfH. V4: Part of population synthesis. Simple rates. V5: Pull out as a separate module to facilitate model upgrades and scenario testing. Keep rate-based model. Investigate improving categorization. 29

  30. Place of Residence Place of Work (PoRPoW) Assigns specific workplaces (TAZ) to each worker based on worker employment status & occupation. V5: Keep the basic V4 approach (doubly-constrained entropy/gravity model). Can the explanatory variables be improved? Income? Inclusion of external jobs/workers within the model. Enhanced spatial structure effects: Central Place Theory concepts. Regional structure. 30

  31. Auto Ownership EVs. Much work going on in this area; will incorporate. Have a PhD student working on this (Mwendwa Kiko). AVs: Not in V5.0. Privately-owned Avs represent a major change in activity/travel modelling. AV-based ridesharing is easy to handle if we have implemented the ridehailing model. 31

  32. Daily Activity/Travel Demand: TASHA2 32

  33. Key Issues to Address in TASHA2 1. Improved feedback between TASHA modules. 2. Incorporating new mobility services. 3. Modelling WfH/hybrid work. 4. Many others: 1. Virtual/in-home activities. 2. Modelling spatial choice. 3. Active transportation. 33

  34. Feedback within TASHA The current TASHA activity episode generation & scheduling components are very sequential in design, with little feedback. As a result: Activity episode generation is quite inelastic. Some inconsistencies between calculations in different modules can occur. More interactions between generation, scheduling, mode choice and NWS location choice are required. Also need to deal better with: Supervision, etc. of dependents (e.g., children). WfH effects. These are the oldest parts of the software & have not been touched in a long while. In V5 we will open up the box to improve these interactions & update the code. Will need to experiment with alternative structures. Iteration within TASHA. Gibbs Sampling? 34

  35. Incorporating Mobility Services PhD student Shuoyan Xu will be implementing a model of ridehailing service/performance in V5, based on Francisco Calder n s prototype. We have access to City of Toronto VfH data to support this work (plus TTS & THATS data). Tour-based mode choice model will be updated accordingly. 35

  36. WfH Major challenge! It is far from clear that we can continue modelling a single typical day . Do we need a multi-day model? Options include: Run 5 one-day models. Experimenting with week-long model. THATS survey will support both options. Feedback effects of WfH on: Activity generation? Auto ownership? PhD student Mohammad Haghighi is working on week-long modelling and can help with this work. 36

  37. Other Issues 37

  38. Expansion to the GGH! GTAModel has always been focused on the GTHA, with the remainder of the GGH being treated in a very aggregate, non-agent-based way as external zones. Although a version of the model has now been extended to the Region of Niagara. It would be good to extend V5 to cover the entire GGH. This, however, will be a heavy lift for the small TMG staff, at least in the short run. Perhaps we can second regional agency staff to help us with some of the data assembly, model testing, etc.? If we do take on the whole GGH, I want to explore some sort of hierarchical treatment of regions within the overall study area: E.g., Niagara, Waterloo, etc., while connected with the GTHA are also economic regions in their own right, with their own spatial-socio-economic structure. 38

  39. Time-Series Analysis Pre-pandemic, the intent had been to use multiple TTS years to develop model parameters that were robust over time. The pandemic & its aftermath have called this approach into question. Instead, we will develop V5 based on 2022/23 data and compare parameters, etc. with V4. We will also run V4 on 2022/23 data to see where the key differences are. Have an undergrad student doing her 4th Year thesis on this (Grace Zhang). 39

  40. Staff James Vaughan: Lead software designer & programmer. Model estimation & model system calibration lead. Jeff Mukuka: Network coding & assignment model estimation/calibration. General analysis assistance. Henry Waterhouse: General analysis assistance. Amit Sandhel: XTMF Programming. Postdoctoral Fellows, Ya Gao, Alex Dong, Usman Ahmad: Data preparation. Model estimation & testing. Graduate Students: Mohammad Haghighi: TASHA updates; 5-day modelling. Mwendwa Kiko: Auto ownership modelling. Shuoyan Xu: Ridehailing model. Undergraduate student (Grace Zhang): Comparison of pre- & post-pandemic travel behaviour. 40

  41. Schedule Work will begin in earnest in November. Hopefully TTS 2022 data will be available. TMG staff will have some cycles to spare for this work by then. Postdocs will be on staff by then. And then we ll see how far we can get by the end of March. We have always expected this work to go into the 2024-25 work year. Will provide an update on progress and the work plan at the Dec. 6 workshop. 41

  42. Questions? Further discussion? 42

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#