Transcript Regional Hurricane Evacuation Task Force

Update on
Developing Evacuation Model
using Dynamic Traffic
Assignment
ChiPing Lam, Houston-Galveston Area Council
Matthew Martimo, Citilabs
Review last Presentation
 During Rita Evacuation, evacuation routes
were very congested. “Crawling parking
lot.”
 H-GAC was asked to develop a tool for
evacuation planning.
Challenges
 Large network and demands
 Long trip length and travel time
 Interaction between evacuation and nonevacuation traffic
 Network changes during evacuation period
(eg: contraflow, HOV and toll open to
public)
Goal of this model





Re-generate the Rita evacuations
Provide evacuation demands
Estimate traffic volumes and delays
Sensitive to various scenarios and plans
Apply to non-evacuation planning
(corridor, sub-area, ITS, etc)
H-GAC’s Expectation
 Validation
– Normal Day Traffic
– Rita
– Year 2010 Scenario
 Able to adjust evacuation trip tables for
different situations
 Sensitive to policy factors
 Allow road changes within evacuation
Review – Why DTA?
 Why NOT use traditional (Static) assignment?
–
–
–
–
No impact of queues
No ability to deal with upstream impacts
Links do not directly affect each other
Not conducive to time-series analysis
 Why NOT use traffic micro-simulation?
– Study area of interest too large and complex
– Too much data and memory required
– Too many uncertainties to model accurately
Cube Avenue Technical Facts
 Unit of travel is the “packet”
– Represents some number of vehicles traveling from
same Origin to same Destination
 Link travel time/speed is a function of
– Link capacity
– Queue storage capacity
– Whether downstream links “block back” their queues
 Link volumes are counted in the time period
when a packet leaves the link
Progress on Last Presentation
 Based on TXDOT survey, develop trip
generation model
 Using a simplified and relax gravity model
to assign evacuation demands
 Develop hourly factors for evacuation
traffic and normal traffic reduction
Progress on Last Presentation(2)
 Ramp Storage Adjusted to account for
storage lane and through lane on freeway,
to avoid over-estimate backup
 Network simplification to save memory
 Single class assignment
 72 1-hour assignment to account for
network changes
Computer Limitations
 32 bit computing (Windows XP) limits how
much computer memory can be accessed
by a single process to 2GB.
 Initially the problem size was requiring
more than 2GB of memory and was failing
altogether.
 Previous suggestion: Simplified Network to
reduce memory requirement
Overview for this presentation
 Problem Size
– Greater Houston-Galveston Metropolitan Area
– 72 hour simulation of evacuating vehicles
 Initially strained the available computing
resources
 Mesoscopic modeling versus standard
Macroscopic Travel Demand Modeling
Simplified Network Abandon
 Only Major arterials, highways, and freeways
remained in the simplified network.
 In retrospect, this was a VERY bad idea…
because of the nature of Mesoscopic
Simulation… This will be described in a few
minutes.
 In fact, the more detail available in the
network, the better. We are now modeling
with the full travel demand modeling network.
Multi-Class Assignment
 Single class assignment remove some of the
ability of the model to properly replicate flows seen
on the roadways
 Making calibration more difficult.
 Now model multi-class assignment similar to the
static model, each with their own path sets.





Drive alone free (No HOV, Toll, HOT)
Drive alone pay (No Toll)
2 person free (No Toll, HOT)
3+ person free (No Toll)
Share ride pay (allow everything)
Increase Number of Iterations
 Originally zero to 1 iteration (similar to AON
assignment)
 Vehicles jam to the AON route, cause
extremely long travel time and consume more
computer memory
 Ill-conceived as with each subsequent
iteration, the vehicles learn more about
possible routes and their environment.
 With each subsequent iteration, the model is
more stable, reliable, and easier to calibrate.
Number of Iteration vs Travel time
for Single hour assignment
Packets
 Network are simulated in packets.
 A group of trips with same origin, destination,
and start time.
 Treated as if a single unit
 Each packet can hold any number of trips.
 Tracking and simulating these individual
packets is what consumes the memory. 2GB
can simulate more than Six Million packets at
anyone time.
Limit the Size of Packets
 Originally, the maximum size of packet is
ten vehicles or less
 Large size is to reduce number of packets;
to consume less memory
 With software upgrade and increase
iteration, now is one vehicle trip per packet
 Reduce number of non-integer trips
Non-integer Trips
Example: Drive Alone Free Trip Table
10 million trips
Due to non-integer
trips, the number of
packets ends up being
MUCH larger.
Reduce Number of Non-Integer
Trips (1)
 Alternative 1: traditional bucket rounding
for each hourly demand
 Add fraction trips across column, and
assign a trip when the sum of fraction
equals to or exceeds 1
 Does not reserve column (destination)
total, which is bad as evacuation traffic is
concentrated on a few external
destinations
Reduce Number of Non-Integer
Trips (2)
 Alternative 2: Cross-time bucket rounding
 Summing across time rather than column,
hence preserve origin-destination total
 Too little traffic on early hours because for
many origin-destination, sum of early hour
trips is less than 1 (no packet assigned)
Probabilistic Integerization (1)
 For each origin-destination pair, produce
probability distribution based on hourly
demands
 Simulate integer trip based on probability
 Sum of Daily Trips for each origindestination reserves, and early-hours are
assigned with adequate traffic
Probabilistic Integerization(2)
Changes to the Software
 To properly simulate network changes,
such as reversible HOV facilities, contra
flow lanes and etc, the following changes
were made to the software:
 Ability to turn facilities on and off during the
simulation
 Ability change the capacity of facilities during
the simulation.
 Ability to animate packet during the simulation
Changes to the Methodology
 Previously, break down the 72-hours
evacuation into 72 single hour
assignments to allow network changes
 Now simulate the entire 72 hours of
evacuation in one long simulation, and
turn on contraflow lane or reversible HOV
in the middle of simulation
 Reduces run time from 3 days to half days
Cluster
 Speed up the simulation by distributing the
work to more than one processors
 Now groups of computers can work on
finding the best path for each packet (one
major task).
 While others work on simulating the
packets as they become available (the
other major task).
Volume Delay Curves
 In macroscopic assignment, assigned
volume can exceed capacity.
 The Volume-Delay curves were adjusted
to limit the ability of the model to assign
more trips than the available capacity.
 The speed is too high comparing to reality
Example: Freeway curve
Volume Delay Curves(2)
 On contrast, DTA does not allow volume to
exceed capacity.
 Therefore, speed should decrease sharply
when volume approaches capacity
 Standard speed-capacity curve from
Highway Capacity Manual replaces the
volume delay curve in regional demand
model
Mesoscopic Simulation
When Compared with Macroscopic
Assignment:
– Vehicles take up space and progress
through the network.
– Capacity strictly limits the rate at which
vehicles progress.
– Available Storage strictly limits the number
of vehicles that can occupy a link.
– If vehicles cannot progress they must wait.
– A full link blocks ‘back’ and will impact
upstream links
Theorem of One Bad Link
 In static assignment, volume on one link may
over capacity and does not impact adjoining
roadways.
 In the mesoscopic simulation, when a link is over
capacity, incoming vehicles must queue on
upstream links to wait for their turn
 A link with extremely high v/c ratio could cause
serious congestion on adjacent links
Impacts on Mesoscopic Assignment
 Example of a centroid connector between
a mall (represented by a TAZ) and a
frontage road … It is the only centroid
connector of that TAZ.
 Frontage road has capacity of 1444 vph ,
but than 6000 trip demands during 8am…
 tens of thousands of trips sitting on the
upstream links blocking all the roadways.
 Solution: adding more centroid connectors
Network Clean up
 Incorrect Network coding may cause
illogical path. Its impact could be very
severe in mesoscopic assignment
 Missing turn prohibition
 Incorrect distance coded
 Lazy coding: one coded link to substitute
many links in real world
Impact of Incorrect Distance
 The Frontage road
coded as 0.2 miles
instead of 1.1 miles
 Freeway through
traffic diverts to
frontage road
 Subsequent time
slices showing
illogical backup on
other links
Example of Lazy coding
One link to represent all direct ramps
Lazy Coding
Detail Coding
Calibration
 Now in Calibration Phase of a normal day
assignment
 Identify (and fix) problem spots in the
network using two approaches:
1.A static assignment to check for areas
were Volume greatly exceeds capacity
2.Run DTA on sub-areas for faster run time
and easier problem identification,
particularly network problem.
Conclusion - Discovery
 Sufficient number of iterations is required
to eliminate long travel time and nonsense
backup
 Clean network is necessary
 High V/C ratio link in static model will
cause severe congestion on adjoining
links in DTA assignment
 HCM curve is more suitable for DTA than
volume delay curve for regional model
Conclusion - Progress
 Develop probabilistic distribute to
aggregate and to simulate fraction trips to
integer trips
 Replaces the “simplified” network with full
network
 Multi-class assignment adopted
 A single 72-hours simulation substitute 72
one-hour assignment, saving run time
Continuing Challenges
 Calibrate the normal day scenario
 Mesh evacuation traffic with nonevacuation traffic, as these two types of
traffic behave very different.
 Code traffic signals
 More network cleanup may be necessary
 Trip Table adjustment?