1. Update on Developing Evacuation Model using Dynamic Traffic Assignment ChiPing Lam, Houston-Galveston Area Council Matthew Martimo, Citilabs

2. 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.

3. Challenges  Large network and demands  Long trip length and travel time  Interaction between evacuation and non- evacuation traffic  Network changes during evacuation period (eg: contraflow, HOV and toll open to public)

4. 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)

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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.

13. 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)

14. 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.

15. Number of Iteration vs Travel time for Single hour assignment

16. 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.

17. 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

18. 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.

19. 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

20. 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)

21. 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 origin- destination reserves, and early-hours are assigned with adequate traffic

22. Probabilistic Integerization(2)

23. 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

24. 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

25. 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).

26. 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

27. Example: Freeway curve

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. Example of Lazy coding One link to represent all direct ramps Detail CodingLazy Coding

35. 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.

36. 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

37. 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

38. Continuing Challenges  Calibrate the normal day scenario  Mesh evacuation traffic with non- evacuation traffic, as these two types of traffic behave very different.  Code traffic signals  More network cleanup may be necessary  Trip Table adjustment?