Megapolis Technical Layout The TRACC TSM Group: Vadim Sokolov Joshua Auld Michael Hope

Core Megapolis Modules Task Scheduler Data Containers Library Logit Model Subprocessor IO Library Batch Iteration Model for Cluster Operation Car Following Model Lane Choice Model En Route Choice Model Route Choice Model Activity Choice Model Destination Choice Model Mode Choice Model Visual Interface / Model Feedback Mechanism

Task Scheduler Acts as a “job submission” system to the computer Takes requests for work with the following parameters – Function to evaluate – Range of data to evaluate on – Simulation delivery time – Estimated run time – Other functional dependencies (if applicable) Submits “job” to an active thread based on the following parameters – Processor affinity of the thread (cache coherence) – Thread workload – Priority of the job

Data Containers Library Specialized data containers to optimize certain aspects of data use API to data structures rooted in STL API, most will be a wrapper around STL structures Possible factors which will be optimized include: – Minimizing dynamic memory allocation/deallocation – Minimizing memory footprint – Maximizing cache coherence for a given traversal pattern (random access, linear access, periodic access, etc…) – Optimizing proper alignment to cache and page boundaries – Minimizing access time/lookup – Automating parallel operation over the structure Data structures will provide thread coherence when necessary

IO Library Library which handles file structures, reading, writing, and serialization for restart Standardized well-documented formats Three main categories: – Relational database/JSON/XML for interdependent files such as network files – Optimized binary files for extremely fast IO (i.e. snapshot, plan, or serialization) – Simple fixed format human-readable ASCII files which are non-interdependent and non-performance critical Serialization engine will ease restart capabilities for the tool as a whole

Visual Interface Use of TransimsVIS for initial feedback Development of additional module used for interactive feedback during model execution Utilized initially for debugging choice models OpenGL-based May be run in “offline” mode as well

Batch Iteration Model for Cluster Operation Tool to design and execute an iteration scheme Utilizes multiple “experimental design” parameters per iteration – For example, an iteration might spin off 4 separate instances (to run on different nodes) which will test 4 parameter variations – the best result will be used as the input to the next iteration Uses light MPI communication and is targeted at cluster operation, although a single stream iteration scheme on an individual desktop computer would still benefit

Logit Model Subprocesor Highly optimized engine to evaluate many classes of logit models – the basis of agent choice in many transportation models Optimizations would include: – Categorization of problem my logit model type – Factoring calculations by agent type, choice type, and choice target – Minimizing operations for the given logit model type – Utilize assembly-level optimizations to ensure smart register and cache usage Paired with a parser to allow users to define their own logit functions for a given module, i.e. destination choice or actuated signal controller

Interaction of Modules Each module has its’ own specified time resolution for syncing with other modules – Ideally each higher resolution is a multiple of each lower resolution – May eventually be user configurable Operations are assumed to depend only on the state of the system at the beginning of the time resolution, thus run independently without syncing over the course of the operation Higher resolution operations thus don’t expect to receive feedback from these modules until the “sync point” Motivation to have multiple resolutions sync is to understand that the evaluation of a high level choice will waterfall to the low level choices (i.e. choosing a new destination mandates a change of route choice) Some “doctoring” upon sync may be necessary to respond to new conditions which occurred dynamically during the execution window (i.e. new route was chosen but an accident occurred in the link just after the current one, mandating a slight correction in route)

Car Following Model Initially based on the Intelligent Driver Model (Treiber, Hennecke and Helbing) Resolution of module is ~.1 second Storage will consist of locating position, velocity, acceleration, and other persistent choice variables on the link itself to ensure cache coherency Parallelization will be achieved by making an agent’s choice for the next timestep entirely a function of the previous timestep i.e. f(t+1)=g(t+1,f(t))

Discretionary Lane Changing Model Discretionary lane changes initially derived from the MOBIL lane changing model (Kesting, Treiber, and Helbing) The resolution of module is ~1 second Non-discretionary lane changes modeled using gap acceptance and lane change execution models (Choudhury)

Tactical/Strategic Lane Change Model Tactical/Strategic lane change behavior modeled using nested logit discrete choice models (Choudury) – Logit models may be translated into Bayesian network for faster execution of lane change The resolution of module is ~4 seconds Separate implementations available across these situations – Freeway Lane Changing – Freeway Forced Merge – Urban Arterial Intersections – Urban Arterial Mainline Lane choice

En Route Choice Model Utilizes D* or D* Lite to dynamically correct a path which was either damaged or deemed suboptimal en route The resolution of module is ~2 seconds Specialized network data structures used to optimize cache membership when evaluating neighboring nodes

Route Choice Model Multiple Routing Algorithms – Non-time dependent utilizes A*based on prevailing congestion conditions – All to one/one to all implementation of label correcting for batch routing situations – Time dependent label correcting – Time dependent A* (?????) The resolution of module is ~2 seconds Specialized network data structures used to optimize cache membership when evaluating neighboring nodes

Activity Choice/Destination Choice/Mode Choice Model ???????????????????

Project Development Track Task Scheduler Design – API Implementation Data Structures Design – API Implementation Logit Subprocessor Design – API Implementation Choice of default algorithms for each module, functional groups Task Scheduler Implementation Individual module design, split implementation into three phases: – Basic: bare minimum to simply get functionality – Advanced: bare minimum to meet validation requirements – Optimized Advanced: bare minimum to meet performance goals – Flexible: generalization to allow custom modules Data Structures Implementation Individual module “basic” implementation Logit Subprocessor Implementation Implementation of basic IO features / link to TransimsVIS Individual module “advanced” implementation Individual module “advanced optimized” implementations Implementation of mid-level interactive visualizer Feedback necessary restructuring to task scheduler, data structures, subprocessor Implementation of advanced IO features Implementation of iteration library Implementation of “flexible” modules Implementation of “flexible” logit subprocessor Implementation of high-level interactive visualizer