Integrated Modeling of the Urban Continuum: Location Choices, Activity-Travel Behavior, and Dynamic Traffic Patterns

1. Integrated Modeling of the Urban Continuum: Location Choices, Activity-Travel Behavior, and Dynamic Traffic Patterns SimTRAVEL: Simulator of Transport, Routes, Activities, Vehicles, Emissions, and Land Investigators: Ram M. Pendyala, Arizona State University, Tempe Yi-Chang Chiu, University of Arizona, Tucson Paul Waddell, University of California, Berkeley Mark Hickman, University of Arizona, Tucson Project Manager: Brian Gardner, Federal Highway Administration, USDOT Peer Review Panel Meeting, November 15, 2010

2. Project Description • Project objective • Develop a set of methods, computational procedures, data models and structures, and tools for the integration of land use, activity-travel behavior, and dynamic traffic assignment model systems in a microsimulation environment. • Universally applicable framework, methods, tools, and data structures • Open-source enterprise

3. Project Description • Workplan • Year 1: Design the model system – concepts, strategies, and constructs • Year 2-3: Develop the prototype model system – procedures, data, and software tools • Year 3: Validate and test the integrated model system; documentation and dissemination

4. Project Description • Project Tasks • Tasks 1-3: Identification of issues/challenges and development of a comprehensive study design • Tasks 4-6: Development of computational/analytical solutions along with integrated data structures and management protocols • Tasks 7-9: Data collection and individual component calibration for test sites; Development of prototype integrated model system • Tasks 10-14: Calibration, validation and policy/scenario sensitivity analysis using integrated model system

5. Design Considerations • Behavioral • Consistency in behavioral representation, and temporal and spatial fidelity • Explicit recognition of inter-relationships across choice processes • Example: Response to increase in congestion from home to work • Short term - Alter route and/or departure time • Medium term - Adjust work schedule/arrangements • Long term - Change home and/or work locations • Computational • Separate model systems can take several hours to run a single simulation • Run times for integrated model systems could be prohibitive • Advances in computational power and parallel processing offer hope

6. Design Considerations • Data • Land use data available at the parcel level • Employment and residential data available at the unit-level (e.g., individual employer) • Higher-resolution network data with detailed attributes and vehicle classification counts by time-of-day • Detailed activity-travel data including in-home activity information • Policy • HOV/HOT lanes, congestion pricing, parking pricing, fuel price shifts • Alternative work arrangements (flex-hours, telecommuting) • Beyond Interface • Make connections across choice processes within a unified entity (as opposed to loose coupling)

7. Model Systems • UrbanSim/OPUS: Land use microsimulation model system • PopGen: Synthetic population generation model • OpenAMOS: Activity-based travel microsimulation model system • MALTA: Simulation-based dynamic traffic assignment model • FAST-TrIPs: Flexible Assignment and Simulation Tool System for Transit and Intermodal Passengers

8. A Project Update • Status of software programming/enhancement • Software programming/enhancement of UrbanSim/OPUS and MALTA complete • Software programming of OpenAMOS about 95% complete • Some remaining work on reconciliation pieces • Some remaining work on mode choice elements for transit • Some remaining work on post-processing for output visualization • Software programming of FAST-TrIPs about 75% complete

9. A Project Update • Status of Interface Development • OPUS/UrbanSim – MALTA interface complete • OPUS launches MALTA • OPUS receives travel skims information from MALTA following completion of activity-travel simulation process • OPUS/UrbanSim – OpenAMOS interface complete • OPUS/UrbanSim simulates long term location choices for synthetic population generated by PopGen • PopGen remains a stand-alone software package at this time • OPUS/UrbanSim launches OpenAMOS for simulating medium-term and daily status choices • OpenAMOS returns control back to OPUS/UrbanSim when medium-term and daily status choices are completed

10. A Project Update • Status of Interface Development • OpenAMOS – MALTA interface 99.9% complete • Interface programmed and tested; both OpenAMOS and MALTA are able to pass information back and forth on a minute-by-minute basis • MALTA calls OpenAMOS and launches dynamic interactive simulation of activity-travel patterns • Some minor debugging underway • Status of Graphical User Interfaces • OPUS/UrbanSim graphical user interface already in place • Initial user interfaces for OpenAMOS and MALTA complete • Continuous enhancement/improvement underway

11. A Project Update • Case Study Site 1: Maricopa County Region • First prototype implementation and testing underway • Application at the ~2000-zone level using MAG model networks • Simulate activity-travel for residents of three southeast cities of the region – Chandler, Gilbert, and Queen Creek • All data and networks acquired and appropriately incorporated into model systems • Model Calibration and Validation • Model calibration and validation processes underway • Not yet completed a full 100% population run for entire 1440 minutes • Simpler test runs on smaller samples underway/completed

12. A Project Update • Case Study Site 2: San Francisco County • Acquiring data for second prototype implementation • Complete UrbanSim data available at parcel level • Enhanced DynusT network for network simulation acquired • Awaiting activity-travel survey data with geocoded locations and secondary level-of-service and socio-economic data • Model Calibration and Validation • Model calibration and validation processes underway • UrbanSim implementation in San Francisco County completed • DynusT implementation in San Francisco County completed; need to enhance to MALTA implementation • OpenAMOS implementation yet to be initiated

13. A Project Update • Sensitivity and Scenario Analysis • Sensitivity and scenario analysis yet to be initiated • Need to complete base year calibration and validation before launching sensitivity and scenario analyses • Model Documentation and Training/Dissemination • Model documentation under preparation • Need to document software systems extensively • Need to document results of prototype implementation in two test sites extensively • Dissemination of research underway • Presentations at ITM2010 and WCTR; poster at TRB2011 • UrbanSim, PopGen, and DynusT workshops/training/webinars conducted on numerous occasions • Plan is to conduct additional webinars and training sessions in 2011/2012

14. A Project Update • What we intended to have done by today • Full model runs of integrated model under a highway-only (no transit) simulation for full population of Case Study Site 1 (Chandler, Gilbert, Queen Creek) • Include all travel that is undertaken by residents of these three cities (i.e., travel may occur outside of these three city boundaries) • Show results of simulation at various stages • Location choices simulated by UrbanSim • Medium term choices and activity skeletons simulated by OpenAMOS • Dynamic activity-travel patterns simulated by OpenAMOS-MALTA • Network conditions by time of day simulated by MALTA

15. A Project Update • Where we seem to be today… (a moving target!) • UrbanSim simulation of location choices complete • OpenAMOS-MALTA simulation of small sample of full population of three cities is happening… • Show results of simulation at various stages for the small sample runs • Iterative process to convergence not yet completed • Plan to have simulation results to show during this meeting, perhaps on second day

16. Test Area

17. OpenAMOS • Open source Activity-Mobility Simulator • Fully functional self-contained software system coded in Python and using a number of supporting software and utilities for Python • Very modular in nature allowing users to pick up individual pieces that simulate a certain aspect of activity travel behavior • Has its own graphical user interfaces (under continuous enhancement) coded in PyQT, which are separate from the core program • Models activity-travel participation as the day evolves with due consideration for time-space constraints, inter-person interactions within households, and on-the-fly activity generation • Considers various market segments with separate models for each segment – adult workers, adult non-workers, non-adults

18. Components of OpenAMOS • Ordered probit model of vehicle ownership • MNL model of vehicle type choice for each vehicle in the fleet • Future versions to employ MDCEV model and new forecasting procedure developed by Pinjari and Bhat

19. Generating Time-Space Prisms

20. Child Status and Allocation

21. Child Status and Activities

22. Adult Status and Child Allocation

23. Adult Status – No Child Allocation

24. Activity-Travel Simulation

25. Activity-Travel Simulation

26. Activity-Travel Simulation • Rule-based heuristics to reconcile activity-travel patterns and eliminate inconsistencies • Continuously enhancing intelligence in system without compromising behavioral flexibility • Choice models: MNL models • Prism vertex models: Stochastic frontier models • Continuous models (duration): log-regression models • Count models: Ordered probit • Models estimated on 2008 MAG NHTS data

27. Model Design: SimTRAVEL

28. Model Design

29. Model Design

30. Model Design

31. Integrated Model: Supply and Demand O-D Travel Times for Destination and Mode Choice Modeling t =1 min t =0 OpenAMOS Origin, Destination, Vehicle Info for Vehicle Trip 1 Origin, Destination, Vehicle Info for Vehicle Trip 2 Arrival Time Person(s) reach destination and pursue activity New link travel times DynusT/ MALTA Vehicle is loaded and the trip is Simulated 24 hr duration 6 sec. interval Update Set of Time-Dependent Shortest Paths – 1440 paths per O-D Pair

32. Activity-Travel Simulation • After each iteration of dynamic interface, a skims table by time-of-day is saved (24 tables of size ~2000x2000) • OpenAMOS uses this set of skims tables to sample locations that may be visited within the available time left in the prism • At any point in the prism, OpenAMOS computes time remaining to next fixed activity location • Sample locations that can be visited while accommodating travel time to the location and from the location to the next fixed activity • Actual arrival time determined by simulation in MALTA • Activity durations and subsequent activity engagement affected by actual arrival time

33. Model Design • Model activities and travel at one-minute resolution • In each minute, activity model provides list of persons and vehicles with origin-destination travel information to dynamic traffic assignment model • Dynamic traffic assignment model routes the trip along time-dependent shortest path to destination • Dynamic traffic assignment model simulates movement of vehicle at 6-second time resolution • Arrival time simulated by dynamic traffic assignment model determines set of trips/persons passed back to demand model at any one-minute time step • Activity duration is adjusted based on actual arrival time

34. Data Transfer • After every minute, demand model provides a list of vehicle trip records to the supply model • Vehicle trip record  vehicle id, vehicle trip id, person ids for the occupants, origin, destination, and departure time • After every minute, supply model communicates back arrival times of vehicles that have reached their destinations; subsequently demand model makes activity engagement decisions • Supply model routes and simulates the vehicle trips; vehicle locations are updated every 6 seconds in the simulation • The above steps are repeated to generate activity engagement patterns for all individuals for an entire day

35. Model Design

36. Convergence in Integrated Model • Convergence on the supply side well-established and incorporated into modeling paradigms • Compare origin-destination travel times from one iteration to the next • When travel times show no further change, process comes to a close • Set of time-dependent shortest paths will not change further • How does one check “convergence” on the demand side? • Comment: Objective is to find travel patterns that are in equilibrium with network. Test should be whether travel patterns are stable; not whether travel times are stable.

37. Convergence in Integrated Model • Produce aggregate 30-min trip tables (by purpose/mode) at end of each iteration and compare between iterations to monitor stability; use averaging schemes to bring process to closure • At more disaggregate level, examine time-space prism vertices for each individual in synthetic population • Time-space prisms are based on origin-destination travel times (travel speeds) and therefore well connected to the supply side • If time-space prisms show “stability” from one iteration to the next, process may be approaching convergence • Represents a more disaggregate convergence check, but need measures of difference and comparison – and threshold criteria for convergence

38. Software Development • Completely open-source and freely available to community • Programming Languages • Python used for UrbanSim and OpenAMOS • C/C++ used for MALTA/FAST-TrIPs • Database Management • PostgreSQL is commonly supported in all model systems • Other database protocols are supported in the individual model systems including SQLITE, MySQL, text, HDF5 binary format • Graphic User Interfaces • Individual Model Systems - PyQt4 used for GUI’s in PopGen, OpenAMOS and UrbanSim; Java for MALTA • Integrated Model – OPUS serves as Master Controller to launch various model systems

39. Testing Environments • Option 1: Single workstation environment • The three model systems will be run on a single high end workstation • Will enable faster and smoother integration • Allow application to small and medium metropolitan regions • Option 2: Distributed computing environment • Various solutions are being explored • Running the model systems in a cluster computing environment using MPI/OpenMP protocols • Geographically distributed computing wherein individual model systems will be running on remote computers and will interface through network/socket programming protocols • These solutions will allow for application of the Integrated Model for large metropolitan regions

40. Data Flow between Model Systems • UrbanSim • OpenAMOS • MALTA

41. Interface: UrbanSim and MALTA • Data flow between the model systems • One way: UrbanSim ← MALTA • Data exchanges • Accessibility measures (←); Travel times and costs (←) • Implementation • Transfer of skims data using text files • UrbanSim will read, parse, and populate databases with skims to compute accessibility measures • Future versions may implement a spatial query based process

42. Interface: UrbanSim and OpenAMOS • Data flow between the model systems • One way: UrbanSim → OpenAMOS • Data exchanges • Household location choices (→) • Fixed activity location choices (→) • Activity locations by type (→) • within a time-space prism • Implementation • Location choices • Written to synthetic population file • Activity locations by type • Data provided by UrbanSim and processed by OpenAMOS to lookup

43. Interface: OpenAMOS and MALTA • Data flow between the model systems • Two way: OpenAMOS ↔ MALTA • Data exchanges • Travel times and costs (←) • Information about trips within a simulation interval (→) • Arrival information about trips at the end of a simulation interval (←) • Implementation • Embedded Python approach • MALTA driving the simulation, calling modules of OpenAMOS to get and send trip information

44. Skims Generator (Future) • The API will support only one-way data flow • from MALTA to UrbanSim or OpenAMOS • Implementation • MALTA processes queries from the individual model systems and returns results • Incorporates a hybrid-approach for building and scanning a network using link travel times • provides memory efficiency over the traditional approach of querying O-D travel time matrices • Implementation • skims_generator.process_query(‘what is the travel time between location A and location B’) • skims_generator.process_query(‘what are the locations accessible within a time-space prism’)

45. Dynamic Activity-Travel Simulator • The API will support two-way data flow • from OpenAMOS to MALTA and vice-versa • Implementation • Key component for the dynamic handshaking between OpenAMOS and MALTA • MALTA driving simulation and gets and sends information in each simulation time interval • Synchronization of models inherent to the dynamic handshaking process • MALTA waits for trips to be loaded onto the network before continuing • OpenAMOS waits for information about travelers that have reached their destination before proceeding

46. Open Source Products • Enhanced model systems for modeling: • Land use: UrbanSim • Population Synthesis: PopGen • Activity-travel demand: OpenAMOS • Dynamic traffic patterns: MALTA/FAST-TrIPs • Code residing in repositories • UrbanSim: https://svn.urbansim.org/src/tags/ • PopGen: http://code.google.com/p/populationsynthesis/ • OpenAMOS: http://code.google.com/p/simtravel/ • MALTA: https://dev.urbansim.org (MALTA directory)

47. Wiki Site http://simtravel.wikispaces.asu.edu

48. Wiki Site

49. Code Repository http://code.google.com/p/simtravel/