Open Platform for Urban Simulation (OPUS) and Overall Integration

OPUS is the proposed software platform for integrating the configuration and operation of the integrated model system combining UrbanSim, AMOS, MALTA and TrAM. Details on how this overall integration is being designed are provided in this section.

OPUS Infrastructure - Currently Implemented

• OPUS GUI and XML - based configurations
• Example of an Existing OPUS Configuration for Interfacing UrbanSim and Emme/2

Software Options to Interface Heterogeneous Models in Python, C++ and C

• For simpler arrays like vehicle_trips, person_trips, vehicle_arrival_times:
  • Here is an overview article for the various options
  • SWIG is the most standard, if somewhat heavyweight approach to wrapping C++ and exposing it to Python
  • Boost.Python is an interesting alternative to SWIG, and may be more relevant given the other functionality available in Boost, such as the Graph library (see below).
  • PyUblas Library uses Boost.Python and accesses the Boost.Ublas library for array handling and linear algebra
• For graph data structures
  • NetworkX (Python based),
  • Boost Graph Library (BGL) (C++, has Python bindings, and there is also a Parallel BGL project)
  • May need to code special-purpose queries, e.g. to accumulate list of links accessible within time window from a specified link.
  • Example: OPUS dataset defining graph, and minimum path using djikstra, based on the NetworkX library: https://svn.urbansim.org/src/trunk/transit_accessibility/datasets/edge_dataset.py
• Infrastructure for Inter-Process Communications (IPC), for communicating between processes running on different machines
  • MPI and mpi4py could be used for distributing the models and coordinating communication among them
  • Python has built-in support for socket programming as of version 2.6.4
  • Here is a brief tutorial on using Python for inter-process communication and using sockets to develop a network client-server application.
  • Propose to create an OPUS ModelServer class, extending the existing OPUS ModelCoordinator support for controlling a distributed simulation, with component models running on specified IP addresses.
  • The Qt4 Graphical User Interface library used to develop the OPUS GUI also supports network programming at a socket level, which would provide a capacity to control or access a distributed simulation being controlled by a model server.
  • In addition to a desktop GUI to configure and launch a simulation, a web-based monitor/controller to connect to a model server may also be useful. Django is a robust Python web framework that would provide good support for this functionality.

Model Controller Design

MALTA API Development and Implementation

There are two MALTA components that will be accessed by UrbanSim? and OpenAMOS? within the integrated modeling framework. And two different API will have to be built; one each for accessing the functionalities within the following two components within MALTA.

1. MALTA SKIMS Generator

1. The API for this need not handle any simulation clock synchronizing as this component does not entail any simulation and is based on the “the travel experience from the previous day”; the API will only need to listen for queries and return results in the form of numpy arrays

2. This component will provide the accessibility measures for long-term location choices in UrbanSim?

3. This component will also provide the feasible activity destination locations in any open prism, the travel times for activity location pairs etc. Typical queries from OpenAMOS? will be of the form

• Query 1: What are all the destinations that are accessible within a 2 hour period given that the agent's current location is A (at 6:00 PM) and agent needs to be at location B (at 8:00 PM). Once the results of the query are obtained, the OpenAMOS? activity-travel simulator will generate the activity-travel decisions of the individual within the time-step under consideration. Also the travel skims including the travel time, travel costs etc. should also be included in the output that is passed back. These queries will be generated in the Activity-travel Pattern Simulator Component of OpenAMOS?.
• Query 2: All the locations of fixed activities (school/pre-school) that are within a 1 hour driving distance from their current home location H. These queries will be generated in the Fixed Activity Location Choices component of OpenAMOS?.
• Query 3: What is travel time to the next fixed activity given current Location A and next location B at 3:30 PM. These queries will also be generated in the Activity-travel Pattern Simulator and the Child Daily Status and Allocation components of OpenAMOS?.

4. As noted in the attached model controller design, this object will be initiated by the model controller (as a global object) and will be accessed by the individual model systems (UrbanSim? and OpenAMOS?) as needed.

5. Within the simulation of any year, this global object will handle queries for the longer term choices of individuals within UrbanSim? and also for making the short term activity-travel choices within OpenAMOS?.

6. Also across iterations the data (travel times across links by time of day) on which the network graph structure is constructed needs to be updated and new graph constructed to reflect “the travel experience from the previous day”

2. MALTA Dynamic Activity-travel Simulator

1. The API for the dynamic activity-travel simulator is where we are having the most difficulty envisioning the actual implementation

2. Unlike the API for the SKIMS Generator, the API for this should also be able handle simulation clock synchronization or in other words be able to stop and start in response to API calls; this is in addition to the background processing which involves simulating the trips that are provided by OpenAMOS? and also passing back information about travelers that have reached their destination.

3. Is the following description of the OpenAMOS? and MALTA operation with respect to the API implementation accurate?

• As per the attached model controller design, the API for this will be initiated by the OpenAMOS? model system and a simulation clock will be maintained by the OpenAMOS? model system to send trip info at the end of each simulation interval.
• At the beginning of an iteration, MALTA will load the network in the memory and run all the bootstrapping procedures required to start the simulation run

• This process can be initiated by calling a function MALTA_API.initialize()

• MALTA will then wait for trip information from OpenAMOS? about all trips that need to be loaded onto the network

• No processing needs to be done by MALTA_API at this instant, and all the elements/objects initiated by MALTA will remain in the memory

• At the end of first simulation time interval (Δt), OpenAMOS? passes information about the trips that are to be loaded onto the network

• This process can be initiated by calling the function MALTA_API.run_trips(trip_info).

• The trips are simulated for time interval Δt

• The arrival information of the travelers that have reached their destination are returned as a result of the invocation MALTA_API.run_trips(trip_info) as traveler_info
• At this time MALTA stops simulating and waits for the next invocation of MALTA_API.run_trips()
• Both trip_info and traveler_info are numpy arrays

• We repeat the last two steps for all time intervals within a day.

Questions with respect to the MALTA API operation:

• Can MALTA stop simulating and wait at the end of every simulation interval for the next invocation of MALTA_API.run_trips() at which point it will continue simulation?
• Should entire MALTA be wrapped so that the elements which are generated by MALTA_initialize() will stay in the memory and are not deleted within an iteration across MALTA_API.run_trips(trip_info) calls?
• Or should we only wrap parts of MALTA in which case the elements may be deleted across MALTA_API.run_trips(trip_info) calls?
• The last two steps are related closely with the scope of the API and other objects that are created.

---

-- PaulWaddell - 05 Nov 2009