Megapolis Technical Layout

The TRACC TSM Group:Vadim Sokolov

Joshua AuldMichael 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