Cube Update

The “Latest and Greatest” from the ‘labs  Cube Base 4.2 with Cube 5.0 Beta  Cube Voyager 4.2  Cube Cluster  Cube Avenue  Cube Land (in final development)

New Release: Cube Base 4.2 Cube Base 5.0 Beta

Some of the New Features in Cube Base 4.2  Enhanced Avenue support (animation, Google Earth export, etc)  Enhanced LOG file support for transit link splitting  Enhanced MATRIX viewing of up to 255 matrices on a single file  Open/create/edit Access database files  Create Cube personal geodatabase  Option to operate as Cube 5 Beta

Cube 5 Beta – Embedded ArcGIS  Provides geoprocessing functions based on ESRI Technology  Based on ArcObjects from ArcGIS Engine  Provides enhanced GIS capabilities to Cube users at no additional cost  Uses ArcGIS license and extensions already on your computer but it doesn’t require them  Supports personal geodatabase (MDB) with enterprise geodatabase supported in subsequent releases  FYI- Demonstrated/Presented at GIS committee yesterday

Cube Base 5 Beta “Basics”  Two graphical windows: –The new GIS window (‘cube 5’) –But still have access to the 4.x “VIPER” view  Stores all data in MDB personal geodatabase format  Allows the user to put multiple networks, TAZ data and other SHP format files into geodatabase to be accessed by various model steps

Includes a Geodatabase Manager and Reads MXD Files Directly

Offers Both Map Views and Layout Views w/ ESRI-style Editing Tools

Other Features  Offers “on the fly” projection management  Full library of ESRI symbology tools  ArcView-style mapping tools

Cube Voyager 4.2

Some of the Things New to Cube Voyager  DBI processing (automatic sorting, merging, auto array access, etc)- key for GIS Integration  Directly read/write MDB files  Supports matrix estimation for public transport modeling (with Cube Analyst)  Enhanced toll modeling tools  Specialized tools for FTA New/Small Starts modeling –Updates to PT –Read/write FTA User-benefits matrices

New- Path Based Tolls  Path based tolls for closed toll systems (where you get on/get off) in v4.2 for implemented for FDOT & the FL Turnpike –Requires specific network coding conventions for on-gates, off-gates and toll facility links –Requires a toll matrix specifying gate-to-gate tolls by toll set in DBF or MDB format  The presence of the TOLLMATI keyword on the PATHLOAD statement triggers toll gate-to-gate path building prior to path building  Links between toll gates are replaced with pseudo links whose cost are the concatenated cost of the underlying links plus the gate to gate toll.  Path building then uses these gate-to-gate pseudo links which include the gate-to-gate tolls as a component of the cost

Background of Recent Developments for PT To Support FTA New/Small Start Analyses  US Federal Transit Administration has used “legacy” approaches to PT analyses –All or nothing paths –Choice decisions made by mode choice (vs. transit path builder) –Typified by TRNBUILD or INET  Consistency in assumptions between alternatives very important  Ability to identify project (i.e. FTA funded project) benefits critical  Multi-path transit results make it very hard to sort out exactly where benefits come from

PT’s Benefits over Legacy Systems  Better represents complex fare systems  Better represents access/egress connectors  Better able to look holistically at transit system to find realistic routes  Complex select link / select node / select line / select mode capabilities  Can easily tie into Cube Analyst for matrix estimation from passenger count data

New Features  BESTPATHONLY- When BESTPATHONLY=T the evaluation process identifies a single best path, onto which all demand is loaded. The enumeration process also changes its mode of operation: Best paths using more then MAXFERS transfers are not enumerated, making higher MAXFERS settings appropriate.  MUSTUSEMODE specifies which transit modes must be used on a route for it to be included in enumeration or evaluation. Where two or more values are specified, the route will be enumerated if any of the specified modes are used. The specified modes should not include non-transit modes.

New Features (continued)  MUMEXTRACOST is a limit to the additional cost of a route when MUSTUSEMODE is used in enumeration, compared with the cost of the cheapest routes not using the must-use modes. For an origin-destination pair, if the cheapest route (not necessarily using the must-use mode) is 23, and MUMEXTRACOST=30 then routes using the required mode, and having a cost up to 53 (23+30) will be enumerated.  Increased of Maximum connectors by mode to a node to 999

What does this mean?  Can build paths based on actual or perceived times without large biases to perturb paths  Get and assign a single path IJ  Meet and exceed FTA requirements to identify/isolate a project’s impacts  Can better account for areas with large number of options for transit access such as downtown  First demonstrations in Jacksonville, FL and Houston, TX models show process works as intended  Give clients flexibility to migrate to multi-path approaches in the future as FTA’s requirements change.

What’s Coming  FTA looking at ways to get out of multi-path models project-specific impacts  Possibly simplify mode choice models so that choices are made in transit path builder  Development of sketch planning tools to provide another benchmark or comparison of proposed (not yet existing) system in an urban area  Timetable-based methods of evaluating effects of timed transfers and infrequent service

Cube Cluster The tool to dramatically reduce model run times

New Extension for Cube Voyager: Cube Cluster  Brings very large time reductions in model runs  Provides 2 types of savings: Multi: example: take a three time period run and run the mode choice models on three PCs simultaneously Intra: example: run one mode choice model over multiple PCs.  Time savings can be substantial Take a 10 hour run model and put across 10 pcs. One example’s processing time reduced to 1 hour and 10 minutes  Architecture: 1 desktop license plus –Use existing full licenses, or –Add multiple, low cost ‘node’ licenses  Tests have been run using 100 processors

New Extension for Cube Base: Cube Cluster

Cube Cluster Multistep Processing  Works with ANY program or group of program steps including user-written programs –Mode Choice, Trip Generation, etc. –SAS, SPSS or any other software system  To implement Multistep –Identify number of cores to be used –Identify model dependencies using Cube Base’s Application Manager (flow chart) –Use CONTROL/CLUSTER to input controls and assign steps to the various cores in your cluster –Make sure model/data are on a common drive letter (e.g. “s”) –Start up the nodes then run the main application –Don’t worry if some/any of the cores are not available- the main controller will pick up any process that is not covered by a designated core

Multistep Approach  Requires an understanding of the dependencies in the model  Is best optimized when the number of cores is known  Gives the biggest “bang” as data transfer (time spent reading/writing data through the network) is minimized  Will reduce run time to the longest of the procedures running concurrently  Understanding run times of each model step helps to make sure clusters are all working equally  It is coordinated by the “WAIT4FILES” command

Cube Cluster Intrastep Processing  Currently works with –HIGHWAY (Assignment & Skimming) –MATRIX (Mode Choice or matrix math)  Works by distributing the number of zones in the model equally across available cluster nodes  Implementing it for PT is in development  To implement Intrastep –Add 1 line of script to HIGHWAY/MATRIX step –Start up nodes –Run model –Again, don’t worry if any of the nodes is not available, Cluster will distribute the load among what is available

Intrastep Approach  Is the easiest to implement  Compared to Multistep –Requires no understanding of the dependencies in the model –Self-optimizes to the number of available cores –Is sometimes slower than multistep as data transfer time across the network is added –Requires a little caution depending on how your scripts are written  Can actually be nested inside of a multistep to take advantage of available processors when the multistep has dependencies that prohibit too wide a distribution

Cube Cluster Case Studies Ohio DOT/Columbus  Twenty Iterations of Highway Assignment  2 Computers with 2 dual cores each  Results:

Cube Cluster Case Studies Minneapolis/St. Paul

Cube Cluster Case Studies St. Louis, MO

Cube Cluster Examples Multistep (Controller & Flow Chart)

Cube Cluster Examples Intrastep (script & menu)  One line command to implement –DISTRIBUTEINTRASTEP PROCESSID='SERPM', PROCESSLIST=1-6  Can be interactive in the Cube menu system

Cube Cluster Examples Cube Cluster Management Utility

Cube Avenue The tool to evaluate traffic operations in planning models

Transportation modeling tools  Macroscopic Modeling  Mesoscopic Modeling  Microscopic Modeling

Macroscopic Modeling  Macroscopic Models generally consider the entire system and estimate routing and flows through a network for a time period.  Currently used for almost all strategic (long-range) planning  Very fast analysis of very large areas.  Models the behavior of people taking into account: –Why people are making trips –Why they select a particular mode –Why they select a particular route

Mesoscopic Models  MESOscopic are MORE detailed than MACROscopic travel demand models but are LESS detailed than MICROscopic simulation models.  Cube Avenue, a mesoscopic dynamic assignment model is available for CUBE.  With mesoscopic models, it is still possible to quickly analyze larger areas with a more detailed model which overcomes the pitfalls of the macroscopic travel demand models. –Takes into account intersection configurations and controls –More detailed estimates of delay, travel time, and capacities –Enforces capacity limitations and the effects of queues ‘blocking back’ –Models flow curves and changing demand throughout an analysis period –Allows vehicles to respond to traffic conditions and change their route

Cube Avenue  Represents vehicles as discrete packets or individual vehicles  Assigns a specific time of departure from the origin point in the network to each packet or vehicle  Routes the vehicles along multiple paths in response to dynamic traffic conditions  Represents queues and bottlenecks including ‘blocking back’ or the formation of queues on a roadway segment or at an intersection which spill back up-stream to block roadway segments which feed into the roadway segments  Quantify impacts of upstream traffic congestion

Typical Cube Avenue Applications  Measure queuing at intersections and merge points in a network  Isolate secondary impacts from one intersection through another  Evaluate the benefits of ITS (intelligent transportation system) projects  Simulate alternative infrastructure, operational, and policy changes to optimize emergency evacuation plans and strategies  Test strategies to improve arrival and departure from stadiums and other special-event facilities  Evaluate both region-wide and corridor-level impacts of traffic as it changes in time  Better evaluate TDM impacts on operations

Dynamic Traffic Assignment Build TOD Vehicle Trips Establish Dynamic Assignment Parameters Dynamic Traffic Assignment

Which Tool to Use and When?  Traditional regional macro-scale planning-Voyager  Time-dependent regional traffic simulation- Avenue  Corridor level detailed project evaluation- Dynasim Cube Voyager for regional planning – traffic flows Cube Dynasim for corridor simulation = animations Cube Avenue (DTA) for region- wide simulation – queues/ delays

Cube Land (in final development)

Cube Land Overview  Innovation in land use modeling—via auction/bidding theory  Integrates Cube Voyager’s transport accessibility measures and ESRI’s spatial mapping/analysis capabilities  Works directly with traffic analysis zone attribute data  All agents classes interact and compete  Forecasts land rent/prices to better evaluate development pressures

Cube Land Input Data Requirements  Geography- TAZ  Household Forecasts (user-defined classes)  Employer Forecasts (user-defined classes)  Building Types (user-defined)  Regulations that Govern Use (zoning, FAR, etc)  Subsidies  Initial land use data (usually calibration data)  Accessibility Measures from Transport Model

Cube Land Outputs  For Every Zone –Number of Households by Classification & Building Type –Number of Employers by Classification & Size –Land Rents –Regulations Economic Impact by zone –Environmental Justice Measures Utility Values Winners vs. Losers  A Variety of Reports and Formats Produced –Maps –Tables –Figures –User-specified Queries

Cube Land Technical Specifications  Allocation Methodologies –Equilibrium Allocation Location externalities (neighborhood quality, agglomeration economies) Land rents (using auction process) –Dynamic Stepwise Equilibrium Lagged interactions Lagged land use - transport feedback  Calibration Parameters –Bid Functions –Accessibility Functions –User-specified Functions (crime indices, school quality, etc).

Cube Land In Summary  Based on Modern Economic Land Use Theory –Bid Auction Approach –Land Prices, Utility Levels & Regulation Impacts are Outputs  Stable & Unique Equilibrium Solutions  Explicit Representation of TAZ-based Policies such as zoning, incentives, etc.  Quick Run Times  Minimal Data and Hardware Requirements  Tight Integration with the Cube Family of Transportation Analysis Tools

Questions?