Dynamic, Integrated Model System: Jacksonville-Area Application (2013)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

119 C h A P T e r 4 Model Implementation Demand Model Data Development The proposed model system comprises three primary compo- nents: DaySim, the TRANSIMS Router and Microsimulator, and MOVES. DaySim is a travel demand forecast model that predicts household and person travel choices at a parcel level on a minute-by-minute basis. The TRANSIMS Router and Microsimulator are dynamic traffic assignment and network simulation software that can perform regional traffic micro- simulation on a second-by-second basis. MOVES is the EPA’s latest software for estimating emissions and air-quality impacts. The integrated model links the three model components in an equilibrated model system that provides enhanced policy sen- sitivities at significantly higher levels of spatial and temporal resolution than found in a traditional regional travel demand forecasting system. As part of the C10A project, the DaySim-TRANSIMS- MOVES model system was implemented in two regions: Jacksonville, Florida, and Burlington, Vermont. The Jackson- ville region comprises four counties in northeast Florida, covering 3,100 mi2. The regional population includes over 525,000 households and 1.25 million people and generates more than 4 million daily person trips. The Burlington mod- eling area comprises a single county (Chittenden) of approx- imately 620 mi2 and was home to 55,000 households in the base year of 2005. Basic inputs to the activity-based model (ABM) compo- nent include parcel-level information on the location of employment using nine industrial sectors, housing units, enrollment by school level, parking cost and supply infor- mation, access to transit, and numerous buffer-based mea- sures of accessibility. A synthetic population representing the detailed sociodemographic attributes of the regions’ residents and network performance data (or skims) are also key ABM inputs. Parcel Data Use of parcel-level data significantly enhances the sensitivity of the model system to smaller-scale land-use and urban- form measures and provides better sensitivity to travel modes such as bicycles and walking, which are usually shorter and more greatly influenced by attributes of the surrounding phys- ical environment. However, developing a robust parcel-level base-year data file can be time consuming. Establishing the baseline geographic information on parcel boundaries is often a challenge, as is ensuring that data fields are defined and coded consistently across multiple political entities such as counties. To develop the Jacksonville parcel information, the project team had to perform several types of geographic data pro- cessing. These included identifying and removing non- travel-generating parcels such as highway rights of way and bodies of water, merging into a single parcel any parcels that were the same parcel but spread across separate geographic information system (GIS) shapes with multiple database rows, and developing a set of common fields across the multiple county databases. housing unit Data As was described in Chapter 1, the model system uses parcel- level housing unit information to allocate the model’s synthetic population—which is developed at the travel analysis zone (TAZ) level to incorporate sociodemographic controls that are available only at more spatially aggregate levels—to specific parcels. Inconsistencies between parcel-level information, Census-block information, and the TAZ-level information used by agencies arise frequently and must be rectified. The parcel databases provided by the Jacksonville-region counties did not consistently specify the number of housing units on a parcel, so the project team had to impute this information using a combination of parcel data sources in conjunction with Census-based housing unit information. Multifamily housing presents the largest challenge when imputing housing Conclusions

120 units because these units are prone to being undercounted in tax assessor databases. EmploymEnt Data Employment data are not usually available at a parcel-level and must instead be developed using address-based business estab- lishment employment information. Unfortunately, no single clean, comprehensive, public source for this information exists. Instead, the project team often had to rely on private data vendors though their data often have limitations, such as omitted information on public sector employment and self-employment, as well as other deficiencies (for example, the “headquarters effect” in which employment across all of a firm’s locations is allocated to a single headquarters location). In Jacksonville, a data file of employment locations, which had been extensively reviewed and cleaned, was provided by the North Florida Transportation Planning Organization (NFTPO), the region’s metropolitan planning organization (MPO); that greatly facilitated the rapid implementation of the model system. EnrollmEnt Data School location–level information on enrollment is neces- sary to ensure that the proper number of students is being attracted to each school location. School enrollment data by parcel and grade level are typically easier to develop, as most state departments of education can provide enrollment by school address and grade. However, a fair amount of man- ual effort is required to geocode the enrollment locations, as well as to gather enrollment information on trade and other professional development schools. Parking Data Off-street parking location and pricing information is used in the ABM system to influence mode and other choices. Devel- oping parking capacity and cost data can also be challenging if public agencies cannot provide them, although this informa- tion is used in the model less than the housing, employment, and enrollment data. In Jacksonville, enrollment and parking data were easily acquired from existing sources. Transit Stop Data In addition to using zone-level information on access times to transit, DaySim also incorporates detailed information on the distance to transit, by transit submode. This infor- mation is based on all transit stop locations in the region (as opposed to a file of only transit stops coded in the model networks). The file of all transit stops was provided by the local transit agency and required virtually no additional processing. Intersection Data Unique measures of urban form that DaySim incorporates are the number of intersections or nodes of different types within quarter-mile and half-mile buffers. These intersection types include dead-ends (1 link), T-intersections (3 links), and tradi- tional intersections (4+ links) and help characterize the pattern of urban development. These measures are derived from an “all streets” network that has been updated to include the number of links associated with each intersection. Preparation of this intersection data required some cleaning and manipulation in GIS software. Parcel Data Preparation Tools A utility program was developed to generate the specific parcel input file for DaySim. This program combines information about parcel-level housing, enrollment, and employment and calculates additional measures, such as buffer variables that describe the amount of housing, enrollment, and employment and intersections by type within the user-specified radii of each parcel. The utility also computes the distance from the parcel to the nearest transit stop. Ultimately, the utility tool greatly simplifies and expedites the preparation of the derived mea- sures and generates the primary DaySim parcel input file. The inputs to this tool are all straightforward and well-documented and can be ASCII text files or other user-specified formats. The sizes of the parcel file can vary significantly depending on the region’s size, and that may affect the data development sched- ule. If an agency can provide complete, clean data sets for use as input to the DaySim parcel data preparation tool, then the parcel data development process may be prepared in a matter of weeks. More typically, complete and clean data are not avail- able, and 6 months or more may be needed to develop the required inputs. Future Alternative Parcel Data If the model will be used to support long-range forecasting efforts, then future parcel-level assumptions also need to be developed. Ideally, such assumptions would be derived from a land-use forecasting model, although such models are rarely available. In the absence of such a tool, most agencies either apply tools or methods that split parcels and then populate this new parcel geography with updated data, or simply scale up base-year parcel-level data to match regional or sub- regional employment and housing controls. For the C10A effort, the latter approach was used to develop increased- demand scenarios. Note that not all activity-based models use detailed parcels as a fundamental spatial unit. In fact, the DaySim model can be applied at more aggregate spatial resolutions, such as Census

121 blocks or TAZs. Use of these larger spatial units typically reduces the data preparation burden significantly but also limits the sensitivity of the model system. Synthetic Population In addition to the parcel-level inputs to the model system, a synthetic population of these regions’ residents has to be devel- oped. A synthetic population comprises lists of households and persons that are based on observed or forecast distributions of household-level and person-level socioeconomic attributes and created by sampling detailed Census microdata. These lists function as the basis for all subsequent choice making simu- lated in the model system. All base year 2005 data required to develop the synthetic population using the DaySim population generation component were available from the Census Bureau’s American Community Survey (ACS) Public Use Microdata Sample (PUMS) and Decennial PUMS, Northeast Florida Regional Planning Model (NERPM) model inputs, and the National Household Travel Survey (NHTS). The PopGen software, developed by Arizona State Univer- sity, was used to create the synthetic population, consistent with sociodemographic controls prepared by the project team. The Jacksonville synthetic sample population comprises three segments: permanent households and population, seasonal households and population, and group quarters (GQ) popula- tion. These segments were established to reflect the differences in travel patterns associated with these subpopulations, pro- vide the ability to support seasonal analyses, and be consistent with the specification of the DaySim model. For permanent and seasonal households, the project team controlled for the following socio demographic attributes: • Age of the head of household; • Household size; • Household workers; • Household income; and • Presence of children. For permanent and seasonal persons, these categories included gender and age. The sociodemographic controls were much simpler for the noninstitutionalized GQ population because of limited Census table data for these residents. However, a person- level age distribution was used to properly locate two impor- tant GQ subpopulations: college students and retirement center residents. Finally, a utility program was developed to allocate the syn- thetic households and persons to individual parcels. Only minor difficulties were encountered when developing and vali- dating the synthetic population, and they were easily resolved with changes to the PopGen configuration. Auxiliary Demand Auxiliary demand refers to the regional demand that is not forecast by the DaySim model system but must be represented in the DaySim-TRANSIMS model system to reasonably assess network performance and the impacts of different policies or improvements. In the current project, this auxiliary demand is derived from the existing NFTPO model system. However, the project team had to add spatial and temporal detail to this demand to integrate it with the more detailed demand and supply simulation models. typEs of auxiliary DEmanD DaySim provides detailed estimates of the long-term and short-term travel choices of Jacksonville residents when trav- eling within the region, but this travel demand does not fully represent all trips that use the regional transportation net- works. Commercial and truck traffic make up a significant share of all roadway volumes, typically up to 20% or more. In addition, nonresidents enter the region through key external gateways to access jobs, shopping, or other opportunities, or they may simply pass through the region. Similarly, residents may leave the region to satisfy other needs. Special generators may also create demand not explicitly represented by person travel demand models. Auxiliary Demand Processing Auxiliary demand is generated through processes exogenous to the DaySim-TRANSIMS model system. The total demand and the spatial distribution, mode, and timing of these trips are fixed within a given forecast or horizon year (but will vary across model run years). Network times and costs influ- ence the routes used, however, so the assignment of this auxil- iary demand to network paths is not fixed. Identifying and processing the data required to perform the temporal and spatial disaggregation of the demand segments was relatively straightforward. The spatial disaggregation was primarily driven by the parcel-level land-use information prepared for input to DaySim; the temporal disaggregation was informed by a variety of data sources, such as observed traffic volumes at external stations, traffic volumes by vehicle class, and airport departure and arrival schedules. Ideally, the auxiliary demand models would be revised to incorporate sensitivity to the more temporally detailed network performance measures generated by the DaySim-TRANSIMS model system. Conclusions Developing the parcel-level inputs to the ABM was a relatively straightforward process. The work done by NFTPO and the Florida Department of Transportation (FDOT) to clean the employment data significantly reduced the amount of

122 time required to implement the model. (The project team did have to make relatively crude updates to the employment data in one of the counties.) The parcel file required some addi- tional cleaning to establish reasonable totals of housing units and to address inconsistencies in the parcel geography. School enrollment, transit stops, intersection types, and parking data were all relatively easy to assemble from existing data sources. In addition, development of the synthetic population was a relatively straightforward process given the availability of the data and tools. Nonetheless, the overall effort required approximately 6 months. Auxiliary demand was accommodated within the inte- grated DaySim-TRANSIMS model system by using readily available static methods from the region’s trip-based model. However, to achieve a more spatially and temporally con- sistent, integrated demand-supply model system, revisions to these auxiliary demand components would be necessary. A drawback of the current implementation is that the aux- iliary demand is fixed for each forecast year. That is, although auxiliary demand varies by forecast year, it is not affected by changes in network impedances. Ideally, the auxiliary models would be revised to provide sensitivity to changes in network performance. Network Model Data Development For the TRANSIMS software to generate detailed represen- tations of changes in network performance by time of day, the project team had to develop a representation of the net- work supply, identify means of configuring the network assignment process to generate stable simulations with rea- sonable runtimes, and establish methods for generating net- work performance indicators that can be used by the DaySim demand model. Network Build Tools As with most medium and large MPOs, NFTPO maintains a detailed GIS-based all streets network. It forms the basis for building the networks used in the region’s traditional trip- based travel demand model system. This all streets network was used in conjunction with a number of TRANSIMS net- work processing tools to synthesize a TRANSIMS network. The TRANSIMS tools provide a quick method of developing a detailed TRANSIMS network without a lot of extra data collection and arduous network coding. The tools reformat, regroup, and reconfigure that data into standard TRANSIMS input link and node data files and then synthesize the addi- tional information needed for a network simulation such as pocket lanes, lane connectivity, parking lots, activity locations, and signal and sign warrants. These tools allowed the project team to get the network model running relatively quickly and to use the trip assignment process to identify locations where the synthetic process requires refinement. ALLSTREETS Network One of the key questions of interest to the project team con- cerned the potential benefits of incorporating more spatial detail into the simulation networks. The networks used in most traditional static traffic assignments are relatively coarse, frequently including only minor and major arterials and freeways. Because static assignment models and networks are insensitive to many operational attributes, such as hard capac- ity constraints, concerns rarely arise about the mismatch between demand and supply. In the context of TRANSIMS, however, consideration was given to the trade-offs between using a coarser network that would run faster but may not provide the same degree of network sensitivity. As a result, for Jacksonville, three different network resolutions were created. The coarsest network developed was the PLANNING net- work. This network essentially contains all the links found in the MPO’s current four-step regional modeling network, although significant operation detail was included in the TRANSIMS version. The next most detailed version of the network was the FINEGRAINED network, which pivots off the PLANNING network but also includes additional local through streets to the network. Finally, the most detailed net- work was the ALLSTREETS network, which is equivalent to the NERPM regional modeling network plus all other existing minor streets such as neighborhood streets and alleys. Network Cleaning After the networks were built, a significant amount of additional time and effort were required to correct and debug network cod- ing errors and inconsistencies. At the most basic level, the project team had to fix network topology issues. For example, in numer- ous locations, freeways were found to be erroneously intersect- ing with surface streets. These coding errors would not have been an issue had some of these surface streets been dropped when the baseline network was used to create coarser networks for static assignment. In addition to these basic topological corrections, the project team had to devote significantly more attention to other network attributes because the simulation networks are much more sensitive to coding assumptions than traditional static assignment networks. Specifically, disconti- nuities in the coding of facility types, through lanes, and speeds all significantly affected the network performance. Overall, speed issues were most common, but lane coding discontinuities proved to be most challenging in debugging the networks. Discontinuities refers to inconsistent coding of link attributes for adjacent links. Because lanes are the primary source of capacity information within the simulation, and lane

123 changing is one of the primary reasons for congestion and lost vehicles, lane discontinuity errors are extremely problematic. Lost vehicles refers to vehicles that are unable to complete their assignment paths and get “stuck” in the simulation for more than a user-specified number of minutes. Lost vehicles are highly undesirable because they cause inconsistencies between the demand and supply components. The project team also had to establish on a link-by-link basis whether the lane coding from the master network included parking lanes or turn lanes. Other network coding issues that arose in devel- oping all of the different resolution networks included extremely short links, which can cause congestion problems in the simulation, and intersection geometry, which can affect simulation performance. Intersection Controls In addition to getting the basic network geometric details cor- rect, all the intersection control information had to be correct. This information includes the location, timing, and phasing of signals and the locations of other intersection controls such as stop signs. Regarding signals, for Jacksonville, the project team received a data set of the locations of all signals in the region. Unfortunately, these locations were not linked to the master network data file and did not contain any information on tim- ing. Information on stop sign locations was available only for a subset of the region. Ideally, observed real-world signal timing, phasing, and other control information would be available in a readily usable form and coded in the base network. However, developing this real- world information to code this into the network is an onerous task. For this project, TRANSIMS tools were used to synthesize the timing and phasing of signalized intersections. TRANSIMS includes a number of ways of changing the configuration of the network by time of day. In addition to the roadway configu- rations, traffic controls can also vary by time of day. The signal timing and phasing plans can be adjusted to optimize time-of- day flow conditions. Signal progression tools are also available to coordinate fixed-time signals along specified corridors or throughout a grid system. Demand-actuated signals can include multiple detectors and simulate ramp metering behavior. The signal formats also allow the user to change signal types by time of day. For unsignalized intersections, the project team had to syn- thesize traffic controls for the base year. Note that even if real- world information is available for developing the base networks, the challenge of developing future-year intersection controls under increased demand will remain. Use of some tools and optimization strategies presents not only technical challenges but also poses theoretical and procedural challenges for how to best prepare and analyze future-year networks and how to conduct alternatives analyses. Finally, it should also be noted that after the initial model network build process, all subsequent alternative networks were derived from the base network and manipulated using TRANSIMS tools. Recent updates to these tools have signifi- cantly reduced the level of burden on users to simultaneously and consistently update multiple input network files. Conclusions Developing detailed and usable networks for microsimulation requires a significant level of effort. The TRANSIMS software comes with a wide array of tools to perform many network development tasks; and spatially detailed network data are widely available. However, users should expect to spend on the order of hundreds of hours debugging simulation networks: correcting topological errors, resolving attribute discontinui- ties, and coding intersection controls. The time-consuming effort involves iteratively evaluating, adjusting, and testing the networks by running simulations. In addition, users face numerous challenges when attempting to develop future-year or alternative network scenarios, a topic that was discussed earlier in this chapter. Model Integration The design of the integration scheme focused on a few key questions: • What information does the DaySim demand model need to provide to the TRANSIMS network supply model? • What information does TRANSIMS need to provide to DaySim? • How is the network supply model iteratively executed to achieve an equilibrated, or at least stable, condition? • How are DaySim and TRANSIMS iteratively executed to achieve a stable system solution? Answering the first two design questions concerning the information exchange is relatively straightforward. Answering the second two questions regarding the execution and inter- action of the tools is significantly more complex, forcing users to develop new measures to analyze network and system perfor- mance, prompting challenging questions about the nature of equilibration in the context of complex simulation tools, and highlighting practical issues of runtime. In addition to address- ing these implementation and research questions, a key goal of the SHRP 2 C10A project is implementing the integrated demand-supply model in a dynamic modeling framework that is easily transferable to the local jurisdictions for policy analysis. In support of this goal of transferability, the model system incor- porates a system manager that controls the execution of the two primary model system components: DaySim and TRANSIMS.

124 Information Exchange DaySim provides trip and vehicle information to the TRANSIMS Router to perform network assignment. For the Jacksonville region, this process takes approximately an hour of computer processing time. The resulting activity file includes the internal travel demand generated by regional households. This demand is combined with the auxiliary trips to represent the complete travel demand for the region. trip lists To transmit the estimates of demand from DaySim to TRANSIMS, minor adjustments were made to the DaySim outputs to generate vehicle-trip records, to associate the parcel locations with the activity locations used by TRANSIMS, and to output the records in the format required by the Router. In addition, detailed traveler and purpose-specific information on trip value-of-time is included for use by TRANSIMS. Some of the key advantages of using TRANSIMS with DaySim, rather than using a traditional static assignment model, include • Trips are kept and simulated in list format rather than aggre- gating them to origin–destination (O-D) matrices; • Less spatial aggregation occurs because the activity locations used in TRANSIMS are smaller than TAZs; and • Trip start and end times can be kept in units of individual minutes rather than aggregating them to broad time periods. nEtwork impEDancEs DaySim’s core components use a variety of impedance mea- sures to influence traveler’s choices about daily activity pat- terns, destination choices, mode choices, and time-of-day choices. TRANSIMS produces these measures and provides the information to DaySim. The TRANSIMS supply side model assigns the DaySim internal demand and auxiliary trips on the TRANSIMS network through assignment iterations designed to achieve dynamic user equilibrium convergence of the indi- vidual travel paths. The resulting network performance by time of day is used to generate zone-to-zone travel time, distance, and cost skims for detailed periods for input into the next global iteration. In the current model implementation, the network performance information is created for 22 different time periods (as small as half-hours in the a.m. and p.m. peaks) and for all zone pairs in the model before running the DaySim demand component. TRANSIMS includes tools that can flex- ibly generate network impedance skims at virtually any tempo- ral or spatial resolution with little additional runtime; this is possible because the daily microsimulation of the entire region provides information on changes in network performance by specific times of day. The current solution, which involves iteratively using new paths for all travelers, based on composite travel times across multiple assignment iterations, is effective when the number of time periods and zones is relatively lim- ited. However, it would be ideal to generate network perfor- mance indicators using temporal and spatial resolutions that are consistent with the underlying parcel-level spatial reso- lution and 30-min temporal resolution of the DaySim demand model. A number of schemes to achieve that level of detail were hypothesized, such as implementing efficient multi stage sampling of destinations (and corresponding impedances) at strategic points in the DaySim looping process or tightly integrating DaySim and TRANSIMS so that DaySim can call TRANSIMS to extract the required measures quickly. Because of runtime considerations and project resource constraints, none of these methods was ultimately implemented. Component Linkages and Execution A critical aspect of integrated model development involved implementing and refining strategies for achieving a condi- tion of model system convergence in the network assignment process, as well as for the overall integrated model system. Convergence is necessary to ensure the behavioral integrity of the model system. nEtwork assignmEnt At the network-assignment level, convergence is achieved through the interaction of the TRANSIMS Router and TRANSIMS Microsimulator. The project team extensively tested a variety of configurations of the Router, Microsimulator, and other TRANSIMS tools used in the network assignment process. These included variations on rebuilding paths for all travelers at all iterations and rebuilding paths for both random and targeted subsets of travelers at each iteration, and different methods of calculating link delays and using different levels of temporal resolution when representing changes in network performance by time of day. Interestingly, the methods that seemed to perform best—as measured by traditional link-based relative gap, new-trip–based gap, and stability measures such as aggregate vehicle hours and miles traveled—were among those that are least accepted by the dynamic traffic assignment (DTA) community. The more commonly practiced network assign- ment methodologies, such as the use of updated paths for a successively smaller share of travelers across multiple assign- ment iterations, were often the worst performing. The observed TRANSIMS convergence using these methodologies was rela- tively consistent with the reported convergence of other DTA tools. This performance is critical, as the project team discov- ered that the level of convergence can significantly influence the conclusions drawn from alternative analyses. nEtwork convErgEncE Other key network assignment convergence issues are how to measure network convergence, and how many iterations are

125 required to achieve a converged result. The project team devel- oped both typical measures, such as network link-based relative-gap measures, and new measures, such as person-trip– based-gap measures. These measures were calculated across the entire day, as well as by detailed time period. The project team encountered numerous challenges in developing both link-based and trip-based-gap measures. For example, when calculating link-based relative-gap measures, the total number of vehicles on a given link during a given time period is needed, as well as the travel time experienced by that vehicle during that time period. Deriving those measures is straightforward in the context of aggregate static assignment methods, but it is con- siderably more complex in the context of the regional network simulation model because vehicles may travel on just a portion of a link during a given time period. Similarly, the project team encountered challenges in developing trip-based-gap measures. Conceptually, the trip-based relative gap should represent the difference between the expected time for a given trip, based on the most recent detailed network link delays, and the experi- enced time for the trip in the Microsimulator. In practice, dif- ferences in how various TRANSIMS tools calculate travel times result in negative gaps. Extensive effort was devoted to concep- tualizing and implementing reasonable gap measures. Regarding the number of network assignment iterations needed to achieve a degree of convergence sufficient to support the use of the model, the project team extensively tested and documented the degree of convergence and stability achieved using different network assignment methodologies. The team demonstrated that running additional network assignment iterations was necessary to distinguish differences between policy and investment scenarios. Typically, each model system run comprised three to six system iterations; and within each system iteration, 40 assignment iterations were performed. moDEl systEm convErgEncE Model system convergence is pursued by iteratively feeding the impedances produced at the end of each global iteration back as input in the subsequent global iteration. Convergence is achieved when the impedances are approximately equal to the travel times and costs produced by the final network assign- ment. As with network convergence, the degree of system con- vergence is significantly influenced by the number of times the overall model system is run. schEDulE consistEncy Schedule consistency refers to ensuring that the detailed sched- ules produced by the DaySim model are implemented in the TRANSIMS network model with as much fidelity as possible. This was another concern of the project team. Both the demand and supply models incorporate (re)scheduling capabilities. An open research question is how to address rescheduling when inconsistencies are observed between the demand and supply models. DaySim uses a model to predict arrival time, departure time, and duration at the main destination of each tour—using a temporal resolution of half-hours which is subsequently dis- aggregated to minutes—as well as the departure or arrival time for each individual stop on each tour. TRANSIMS uses this detailed time information when routing trips. In most cases, the travel time experienced by the Router when routing a trip differs somewhat from the travel time assumed by DaySim when it generated the trip. The project team felt the need to define how the integrated model should accommodate these types of discrepancies. While adjusting the trip start time, trip end time, and/or activ- ity duration time in a variety of ways is possible, identifying methods that do not lead to biased model system results is important. In the initial implementation and sensitivity testing of the model system, the project team assumed that travelers would preserve their activity durations and shift the timing of travel to accommodate differences between the expected time used to generate the estimates of travel demand and the expe- rienced time in the network simulation of this demand. This assumption had the effect of causing trips to cascade into time periods later in the day, affecting the model calibration and consistency with the original demand. Subsequent testing, in which travelers were assumed to preserve the time of travel and to adjust their activity durations, demonstrated not only greater schedule consistency between the demand and supply components but also higher levels of link-based network con- vergence. Scheduling consistency measures that incorporate information on the differences between expected and experi- enced departure, arrival, and activity durations are necessary to ensure that the final network assigned demand is consistent with the final calibrated demand model outputs. Conclusions Configuring DaySim to generate temporally, spatially, and behaviorally detailed travel demand information for use in TRANSIMS was straightforward. Configuring TRANSIMS to generate the skims for input to DaySim was also straight- forward. More sophisticated methods of providing TRANSIMS- based impedances to DaySim could potentially be implemented. Options include implementing efficient multistage sampling of destinations (and corresponding impedances) at strategic points in the DaySim looping process or tightly integrating DaySim and TRANSIMS so that DaySim can call TRANSIMS to extract the required measures quickly. However, the runtime implications and required resources for development were felt to be prohibitive, and the current methods provide sufficient spatial and temporal detail. The network convergence equilibration effort revealed that the most effective convergence strategies were often the least acceptable to the larger DTA community, but they

126 were necessary to ensure sufficiently converged assignments within reasonable runtimes. Schedule consistency was iden- tified as another measure of the soundness of a model solu- tion. Extensive testing of the model system was necessary to determine the number of network assignment and model system iterations required to ensure that differences between alternative scenario model results were attributable to these policy and investments and not obscured by “noise” in the model system. Model Enhancements Two of the key goals of the SHRP 2 C10A model system devel- opment effort were to provide enhanced representation of travelers’ sensitivities to price and to incorporate findings from other SHRP 2 Capacity projects. A number of enhance- ments were made to both the DaySim and TRANSIMS model components to achieve these goals. Incorporating Findings from SHRP 2 Project C04 For modeling highway pricing and congestion effects, the rela- tionship between auto route choice and the other travel choices is critical. In previous implementations of DaySim, auto route choice has been handled outside of DaySim itself. For example, for single occupancy vehicle drivers DaySim did not indicate whether a person chose to pay to use a tolled facility. If both tolled and nontolled facilities were available for a traveler’s given zone pair, the network assignment model was left to determine whether a tolled or nontolled route was chosen, typically by minimizing generalized cost and excluding any information about tour purpose, traveler income, or other relevant fac- tors. Enhancements were made to DaySim to include toll and no-toll choices nested under the drive modes and transit submode choices under the transit submodes. When toll cost and/or operating cost are key considerations in choosing a route, each traveler may have different trade-offs between travel time and cost (value of time). DaySim was enhanced to indicate whether the tolled route is used, incorporating infor- mation relevant to value of time, such as tour purpose and travel income. This information is then passed to TRANSIMS, which includes a set of 90 assignment classes that reflect both toll and nontoll choices as well as value-of-time class. DaySim also accepts as input a set of user-class skim files that include information about the predetermined best path for each of three value-of-time classes, two toll and nontoll classes, and the 22 time periods. To the greatest extent possible, the traveler-specific coefficients used in the model were derived from the findings of the SHRP 2 C04 study, Improving Our Understanding of How Highway Congestion and Pricing Affect Travel Demand, both for the functional forms and the magnitudes (work/nonwork, income, occupancy). Price Sensitivity Parallel enhancements to the TRANSIMS tools were also implemented. The original version of the TRANSIMS Router was only able to vary values of time used in the generalized cost formulas at the household level, and thus could only reflect household income. The revised Router can incorporate the trip-specific values of time that DaySim generates; in the cur- rent implementation, approximately 45 value-of-time classes are used in the path building and assignment. The feature can be used in conjunction with the Router’s ability to include or exclude individual links and is configured to mirror DaySim’s toll or no-toll pathtype choices. Network Microsimulator Another significant modification to the TRANSIMS tools involved revisions to the Microsimulator. These changes pro- vided important new capabilities, such as the ability to restart trips that are lost during the simulation, incorporation of improved speed profiles, production of better estimates of network performance at finer resolutions, and support for multithreading across multiple processors which reduces runtimes. Conclusions The enhancements made to the model system were neces- sary to improve the system’s sensitivity and to fulfill the goals of the SHRP 2 C10A project. Updates to the DaySim model system were relatively straightforward to implement, although these updates were not fully completed until a new DaySim software architecture was implemented, which took significantly longer than expected. The updates to the TRANSIMS model components were much more extensive and involved much more time to implement; many of these enhancements were under development during the C10A project. While these enhancements were necessary to fulfill project goals, they undoubtedly also resulted in schedule delays. Model Application The integrated model, controlled through the use of the TRANSIMS Studio software, includes four software compo- nents. All of these components are available free of charge from websites that distribute the open-source software: • TRANSIMS Studio user interface and application manage- ment software; • TRANSIMS and DaySim modeling software; • Python scripts that define the modeling process; and • A folder structure housing network and other input data.

127 Hardware Requirements The model system can be run on computers using either Windows or Linux operating systems. Runtimes for the model system are influenced by a number of factors: • The computing resources available to run the simulation (such as the number of processors, amount of memory available, and speed of storage drive input/output); • The degree of convergence required for a given model application; • The size of the synthetic population used as the basis for all choice making in the model; and • The level of detail of segmentation employed in the model system (such as the number of time periods). The project team successfully implemented the model sys- tem hardware running on Windows and Linux operating sys- tems. Both the Linux and Windows implementations of the model system typically were configured to use between 24 and 32 processing cores, although this number can be flexibly set. Both DaySim and TRANSIMS are multithreaded applications, and TRANSIMS also includes partitioning capabilities. The project team tested a number of alternative configurations of the model system with respect to temporal detail and market segmentation of the skims. As few as four time periods and as many as 22 time periods were used in the model system; some configurations employed no value-of-time segmentation, while other configurations included up to 50 value-of-time segments. The simplest of these schemes could be run with only 2 giga- bytes of RAM, while the most elaborate of the schemes required approximately 20 gigabytes of RAM. Data storage and access influence runtimes so, in addition to having sufficient RAM, the model system (specifically, TRANSIMS) also benefits greatly from the use of fast hard drives for storage—ideally solid state drives. The project team tested the model system using both the Transportation Research and Analysis Computing Center (TRACC) Linux computing cluster located at Argonne National Laboratory and the local Windows-based servers. Application Modes In addition to testing different iterative feedback schemes, the project team also investigated different application modes of the model system. These application modes were developed because the runtimes for a fully integrated and well-converged model run with repeated full regional simulations of Jackson- ville could take up to 4 weeks. Three application modes were conceptualized. The planning application mode involves the iterative exchange of data between DaySim and the TRANSIMS Router but not the TRANSIMS Microsimulator. This mode can be used when the analysis needs are expected to result in regional-scale changes in overall level of travel demand or changes in regional travelers’ destination, mode, or time-of-day choices, but are not expected to be significantly affected by local-scale traffic dynamics. The operations application mode can be used when the analysis requires an assessment of the impacts of a policy or strategy on local traffic dynamics and when these improvements are not expected to result in changes in overall level of travel demand or in destination, mode, or time-of-day choices. The planning + operations application mode represents the fully integrated DaySim and TRANSIMS model system that has been described in this document. In this application mode, the TRANSIMS Router and Microsimulator are used to perform a regional traffic microsimulation as part of every model system global iteration, and microsimulation- based network impedance measures are fed back and used as input to DaySim. The advantage of this application mode is that it provides the full range of sensitivities both to changes in regional demand and to local and regional traffic dynamics. However, these extensive sensitivities come with the significant disadvantage of extremely long model system runtimes. Runtimes The project team extensively tested various iterative schemes to evaluate trade-offs between network assignment and model system convergence and overall model system runtimes. Gen- erally, greater degrees of convergence are required for more spatially, temporally, or behaviorally detailed analysis. How- ever, the level of convergence required for any given analysis is context specific, and the user is afforded many potential means with which to configure the model system and investigate per- formance and runtime trade-offs. Keys and parameters that affect DaySim and TRANSIMS runtimes can be easily config- ured by the user via two primary control files. Table 4.1 shows the runtimes for the Jacksonville model system given the dif- ferent application modes. Staff Resources As with any model system, the level of staff expertise required to interact with the model system will vary depending on the specific nature of how the model is to be used. However, it is safe to say that a higher degree of knowledge and patience is required for interacting with the new integrated model system than for using a traditional trip-based model system. Both the DaySim activity-based demand model component and the TRANSIMS network supply model component are more com- plex than the demand and supply components of a traditional model. However, generating the input data for these model components and further modifying the inputs to reflect alter- native scenarios are both generally straightforward processes, using typically available data as well as the automated tools that have been developed to support model implementation.

128 Challenges The challenges in interacting with the model are primarily associated with debugging the model system. As has been repeatedly mentioned, the network simulation model is very sensitive to small-scale network coding and parameter assump- tions, and the network simulation is subject to frequent failures as input assumptions are being refined. Users must have the ability to understand and mine which data generated by the model system can illuminate the source of simulation prob- lems and also to make informed decisions about how to mod- ify model inputs to achieve the proper model sensitivity. Model users need to have a basic understanding of Python to under- stand the overall model system flow, as well as robust data manipulation, statistical analysis, and GIS skills. Model users need not know C# or C++, the development platforms used for DaySim and TRANSIMS, respectively. Although the model system is relatively easy to configure and interact with, transitioning to a new model system such as the DaySim-TRANSIMS model system represents a paradigm shift. Modeling staff must have a broader set of skills and a willingness to investigate and experiment. The types of analy- sis that can be performed with the new model system are fundamentally different and more expansive from what can be performed with a traditional model system, and the appli- cation and interpretation of model outputs must be thought- fully considered. Use of the fully integrated model system will be most valuable when the proposed policies or strategies are expected to result in regional-scale changes in overall level of travel demand and changes in regional travelers’ destination, mode, or time-of-day choices, and when the policies or strate- gies are expected to be significantly affected by local-scale traf- fic dynamics. These scenarios may include pricing alternatives, capacity enhancements, travel demand management policies, or operation improvements. Finally, note that the hardware requirements of the integrated model system are clearly greater than those of a traditional travel demand model. Conclusions The model system software can be flexibly deployed on hard- ware running either Windows or Linux, and the implementa- tion can be scaled or configured to reflect available hardware resources. The availability of additional processors, more mem- ory, and fast data storage help reduce runtimes of the model system, which can be extremely long for a region the size of Jacksonville. To avoid these long runtimes, the model can be used in different application modes in which either the regional network simulation is not used or the demand is held fixed so that multiple global model system iterations are not needed. A higher degree of staff knowledge and patience is required when interacting with the new integrated model system than when using a traditional trip-based model system. Although many DaySim and TRANSIMS tools exist to assist in data preparation and coding, the model system is highly sensitive to alternative configurations of the model system and to small-scale coding issues. The model system may take anywhere from an hour to many weeks to generate plausible alternative scenarios. Model System Calibration and Validation DaySim Model Transfer Often, the implementation of a new activity-based model sys- tem in a region for the first time involves estimating region- specific coefficients for use in the individual models that make up the overall model system. However, one of the goals of the C10A project was to use existing tools and data to implement the model system. Rather than estimate new models for C10A for the Jacksonville region (which would have involved prepar- ing estimation data sets, testing various model specifications for some or all of the individual model components, and coding the models for application), the project team simply transferred the ABM components and associated coefficients from the existing model DaySim ABM implementation in Sacramento. This approach radically reduced the amount of time required to get the model system up and running. Table 4.1. Application Mode Runtimes Mode Planning Operations Planning + Operations Runtime for Operations DaySim demand estimation (hours) 4.0 4.0 4.0 Assignment iteration (hours) 0.5 5.0 5.0 Convergence checking (hours) 1.0 1.0 1.0 Skimming procedures (hours) 1.0 0.0 1.0 Total (hours) 6.5 10.0 11.0 Iterations Assignment 40 40 40 System 3 1 3 Total 120 40 120 Total System Runtime Hours 195 244 735 Days 8 10 31 Weeks 1.2 1.5 4.4

129 Because the Jacksonville DaySim implementation was trans- ferred from Sacramento, and the model coefficients and alternative-specific constants were initially estimated and cali- brated for the Sacramento region, the project team had to reca- librate the core model components to reflect Jacksonville region- specific travel patterns. Calibration and validation of the entire model system was a highly iterative process that involved mak- ing changes to individual model components to better match observed data and evaluating the impacts of those changes on other model components and on overall model system perfor- mance. One of the advantages of the disaggregate nature of activity-based microsimulation models such as DaySim is that they support more flexibility and realistic calibration adjust- ments than is possible with aggregate trip-based models. NHTS Before calibrating the core behavioral components, the project team had to prepare observed data sets against which to com- pare the model outputs. The primary observed data source for the calibration of the core DaySim component models was the 2009 National Household Travel Survey (NHTS) collected in 2008–2009. For some model components, such as household vehicle availability model and the work-tour-destination model, the NHTS was supplemented with data from the 2005–2009 American Community Survey (ACS). Observed calibration targets for virtually all the components of the activity- based DaySim model system can be prepared using the NHTS or other household survey data. Because transit was not a focus of the C10A effort, detailed transit information, such as an on- board survey, was not used. Additional NHTS survey data was collected in the Jackson- ville region, but the overall number of households, persons, tours, and trips added was relatively small (only 800 house- holds). Since DaySim models travel behavior for a typical weekday, weekend days had to be removed from the data set, further reducing the sample size. Although the NHTS con- tains all the data items required for ABM system development, such a small regional sample is insufficient to completely esti- mate the coefficients in the DaySim component models. How- ever, in the absence of any other data sets containing the information required for ABM development, the project team deemed the NHTS acceptable for deriving calibration targets. In addition to the small sample, a number of other issues with the NHTS also affected the calibration process. These issues included the absence of any person, tour, or trip information for children under 5 years of age, missing travel information for some members of the household, inconsis- tent expansion factors, and unreasonable information, such as extremely high shares of individuals choosing to work at home. To address these calibration issues, persons for whom complete daily travel information was not available were dropped, all observed and estimated calibration summaries excluded children under age 5, and revised expansion factors were developed. Calibration Process The results from each individual model component of the DaySim model were reviewed, and adjustments were made to model coefficients and constants. Although all model calibra- tion adjustments have a simultaneous impact on the model predictions, the calibration effort followed a sequential process from the top to the bottom of the DaySim model hierarchy: adjustments to upper-level models, such as the day-pattern model, tend to affect lower-level model predictions, such as trip-mode choice, more than the reverse. Overall, recalibration of the DaySim model system did not require extensive efforts. Many of the models showed reason- able consistency between the initial estimated and the observed results without any adjustments. For example, the initial esti- mated and observed arrival, departure, and duration results aligned closely. Note that the goal of the recalibration effort was to achieve a generally good calibration and validation across a broad range of model statistics, rather than the highly tuned calibration often desired for regional demand models that are to be used extensively in application. The greatest amount of time was spent calibrating the day-pattern models, which pre- dict the number and purpose of tours and intermediate stops made by each individual. These models often have to be adjusted after the initial calibration to ensure that sufficient travel demand is being generated to match observed roadway and transit volumes. Recalibration of the tour-destination models was challenging because, for a few of the tour purposes, few observed tour records resulted. For these purposes, no adjust- ments to the calibration were made. Calibration Challenges One challenge of the calibration process was that model devel- opment involved the use of multiple sets of regional skims at different temporal resolutions and using different network simulation methods at different points in the project. For exam- ple, an initial calibration was performed using skims for four broad time periods. Subsequently, this calibration was revisited when Microsimulator-based skims for 22 time periods became available, even though the additional time period detail did not significantly affect the calibration. The calibration was further revised when Router-based skims from the fully integrated model system were developed. Note that noticeable differences occurred in the Router-based and Microsimulator-based skims, with the former generally being more congested. The Router- based skims are based on volume-delay functions (VDF) applied at fine time periods such as 15-min intervals, while the

130 Microsimulator-based skims are based on the composite speeds of vehicles in the simulation, at that same temporal resolution. These differences and their implications for model calibration and application warrant further exploration. TRANSIMS In concert with the calibration of the DaySim demand model components, the project team also had to calibrate and vali- date the TRANSIMS network supply model components. The demand and supply components interact to produce the over- all model system calibration and validation. Note that the TRANSIMS network validation process involved tests per- formed using all three network resolutions described in this report. However, the final reported validation results reflected the use of the planning network, which was adopted because of its faster runtimes. Observed Data The observed network validation data set was primarily derived from temporally detailed (typically, 15-min intervals) data sources, such as intelligent transportation system (ITS) detec- tors located on major freeways and telemetered and portable traffic monitoring stations. One of the defining aspects of the C10A project is that both the demand and supply models oper- ate at fine-grained temporal resolutions. The observed data used to calibrate and validate the model must also be tempo- rally detailed; and as a result, the project team had to develop an entirely new, observed-count validation data set. A key chal- lenge in developing the observed-count data was cleaning the available data sets for spatial and temporal consistency. The data sets were also reviewed to eliminate atypical counts, such as those that occurred on extreme weather days or during con- struction periods. Because of the seasonal nature of the Florida population, an analysis of variation by time of year was also performed; the analysis indicated that volumes during the peak spring period in Jacksonville were approximately 7% higher than volumes during the off-peak summer season. And, last, the observed-count locations had to be associated with specific directional links in the networks. Ultimately, approximately 1,000 directional links were tagged with observed counts. Calibration Process Estimated roadway volumes were compared with observed volumes for four broad time periods, as well as at a daily level. Note that, unlike a traditional static assignment model, the TRANSIMS model does not assign demand to the network by broad time period. Rather, the entire day’s demand of indi- vidual trips are loaded onto the network using minute-level departure time information provided by DaySim. However, time period summaries were still helpful in assessing the perfor- mance of the assignment model and informing adjustments to both the DaySim demand and TRANSIMS supply models. Overall, the highway assignment validation by time period looked reasonably good, although the evening time period per- formed worst—perhaps reflecting the cascade effect mentioned earlier in this chapter. Conclusions Transferring the DaySim activity-based demand component from Sacramento to Jacksonville radically reduced the amount of time required to implement this component of the model system. Additional calibration and validation of some of the subcomponents of the model—such as the daily activity pat- tern component of DaySim and the refinement of TRANSIMS networks—was necessary to improve model performance. However, a number of the models required little, if any, recali- bration. Use of the NHTS as the primary observed data source for developing demand model calibration targets was some- what challenging given the limited weekday sample size in the Jacksonville region and other data completeness issues. Ultimately, more time was spent refining and validating the roadway networks than refining the calibration of the DaySim demand model components. This confirms that network microsimulation models are significantly more sensitive to net- work coding assumptions, and more time is needed to identify and resolve these issues. Model Sensitivity Testing Travel demand forecasting model systems are only able to test the effects of policies and assumptions that have been explicitly included in the design and implementation of the model sys- tem; they are not intrinsically sensitive to the increasingly broad range of transportation policies and improvements of interest to decision makers. While most regional models are sensitive to large-scale assumptions about land use and demographics, few are sensitive to more detailed assumptions about pricing poli- cies, or to traffic or travel demand management strategies. Even when models have the capability to address these types of poli- cies, they are typically not sufficiently sensitive to the dynamic interplay between travel behavior and network conditions by time of day to do so; nor can they reasonably represent the effects of road pricing, travel demand management, and other policies. Sensitivity testing of model systems involves the evaluation of the effects of changes in model inputs on model outputs. A key motivating force behind the SHRP 2 C10A project is the need to address transportation policies that are being considered in metropolitan planning organizations around the United States. These policies are not adequately addressed

131 by the current state-of-the-practice travel-forecasting mod- els, so the integrated modeling tool developed for this proj- ect seeks to improve how these policies are addressed. To assess the increased sensitivity of the integrated model sys- tem, a set of tests were designed, implemented and evaluated. These tests were designed to illustrate the unique capabilities of the model system and included pricing, travel demand management, and operations. Pricing Freeway Tolls Two types of pricing tests were evaluated as part of this effort. In the first, a number of scenarios were defined in which free- way tolls varied by time of day. In the second, a number of scenarios were defined in which auto operating costs were modified from the “baseline” condition. For the first set of sen- sitivity tests, three scenarios were evaluated and compared with the baseline alternative. In the baseline alternative, no costs were assessed at any time. In the first scenario, a fixed $0.25/mi charge was assessed for anyone using the freeways during the peak periods. In the second scenario, this fixed, peak charge was maintained, and a fixed $0.10/freeway mi charge was added in midday. Finally, in the third scenario, the fixed peak- period charge was increased to $1.00/freeway mi and the fixed midday charge was increased to $0.50/freeway mi. These values were chosen because a set of similar tolling scenarios was tested for a value pricing project in the Seattle region. The expected responses to these policies—that travel would decline during tolled periods and on tolled facilities and that differences would be observed by activity purpose—were all observed in the model system outputs. In the first scenario, travel declined during the a.m. and p.m. peaks when freeway tolling was in place, but little change was observed midday, which was untolled. In the second and third scenarios, travel declined (whether measured as total trips or vehicle miles or hours traveled) during all tolled time periods, with higher tolls resulting in greater reductions in travel. Interestingly, in all three pricing scenarios, the increases in travel demand dur- ing the evenings were pronounced, suggesting that travelers rescheduled activities to occur when no tolls are charged and when fewer scheduling constraints are present. It was also observed in these tests that total trips by time of day affects dif- ferent purposes. For example, work-related travel was relatively unaffected, but social/recreational travel shifted noticeably out of the peaks and into the evening. Finally, the network-based total delay was higher than the base in all scenarios, as the tolls induce travelers to shift onto more capacity-constrained surface facilities. An analysis by facility type indicated that most of this additional delay accu- mulated on minor arterials. This was likely due to coarseness of the sensitivity test; the tolling scheme was not designed with the specific spatial and temporal extent of network con- gestion in mind. While some peak location congestion was likely alleviated as a result of the tolling, in many locations across the broad tolling time periods, increased costs were not offset by travel time reductions because of the low levels of baseline congestion. Auto Operating Costs For the second set of pricing sensitivity tests, a set of three auto operating cost scenarios was evaluated and compared with the baseline alternative. The baseline alternative assumed a cost of $0.12/mi. A lower-cost scenario of $0.06/mi was tested as well as two higher-cost scenarios of $0.24/mi and $0.60/mi. These tests confirmed that when auto operating costs decline, the share of households choosing to maintain zero vehicles also declines; and as costs increase, the share of zero-vehicle households also increases. However, these changes were relatively modest: a five- fold increase in the assumed per-mile operating cost resulted in only a 1% increase in the number of households choosing to have zero vehicles. In addition, the tests revealed changes in regional tour frequency by purpose, demonstrating that lower costs slightly increased tour making for discretionary purposes while higher costs slightly decreased tour frequency by purpose. In addition, these reductions in tour making by purpose were not consistent across purposes; mandatory work and school tours declined while discretionary purposes, such as personal business and social/recreational purposes, were seemingly unaffected. The declines in work- and school-tour making are partially attributable to more workers and students choosing their home as their usual work or school location. The tests revealed little systematic difference in changes in trips by time of day across the three scenarios, although slight increases in shorter trips resulted from the highest assumed auto operat- ing costs. These shifts did not result in significant changes in network performance or congestion. Travel Demand Management TDM approaches incorporate a wide range of strategies aimed at changing travel behavior to reduce congestion and improve mobility. The sensitivity testing for Project C10A focused on assessing the impacts of a flexible work schedule in which all workers worked fewer days but longer hours on those days. The overall time spent in work activities was held fixed. Because DaySim predicts the daily activity pattern of each individual in the region, it can be used to reflect such a scenario. However, this sensitivity was purely scenario-based. DaySim cannot identify which policies would be most effective at affecting flexible work schedules, though it can be used to estimate the impact on individual travelers’ activity patterns and sched- ules and on the overall transportation system performance

132 assuming that an effective policy is in place. The model results were consistent with expectations based on the structure and linkages of the DaySim and TRANSIMS models. In general, overall levels of activity generation were lower, although the declines in work-related travel were offset by increases in travel for discretionary purposes. The model produced shifts in the distribution of travel by time of day due to the lengthened workday, although—as expected—changes in the destination and mode choices were relatively small. This test did reveal noticeable changes in network performance, with reduced con- gestion across all facility types throughout most of the day and a slight increase in congestion in the evening. That reflects both the later return times from work and increased participation in discretionary activities in the evening. Operations The sensitivity testing focused on a scenario in which sig- nals were coordinated using TRANSIMS tools along three primary regional corridors, with the goal of reducing bottle- necks and improving the overall traffic flow. The DaySim- TRANSIMS model system provides sensitivity to these improvements. Traditional travel demand forecast models cannot typically represent such improvements because of the models’ linkage with traditional static network assign- ment methods which lack detailed network operation attri- butes and have coarse temporal resolution. The initial model results showed some reductions in delay by facility type, particularly during the peak periods. However, closer inspec- tion of the speed profiles along the three targeted corridors showed more mixed results, with the signal progression pro- ducing better speeds in some corridor directions and worse speeds in other corridor directions. In implementing the operational tests, approximately 20 iterations were required to establish a set of baseline signal timings for the entire region that produced reasonable performance results. Before establishing new baseline timings, all the corridor progression changes resulted in significant simulation problems. This occurrence likely reflects that such assumptions are necessarily more detailed in geographic and temporal scope—ultimately more consequential for the performance of the network simulation. The sensitivity of dynamic traffic assignment (DTA) and traffic microsimulation models to detailed inputs suggests that users will encounter distinct challenges when attempting to incorporate these assumptions in a forecast- ing mode, especially at a regional scale. Of all the scenarios evaluated as part of this sensitivity testing, the signal pro- gression scenario required the greatest amount of time and resulted in the least interpretable results. While configuring the other sensitivity test scenarios took approximately 1 day or less, configuring the signal progression test scenario took more than 1 week. Disaggregate Framework Because both the demand and the supply components of the model system are fully disaggregate, the impacts of policies and investments on individual travelers can be traced from long- term choices (such as usual work locations) all the way down to the specific paths taken by each individual traveler on a second-by-second basis. For example, if capacity is reduced on a key facility, the system can determine which specific travelers are affected by this change, and how they are affected. Although disaggregate model results are not reported, this disaggregate framework provides tremendous flexibility for aggregating model results for specific travel markets or communities of concern. In addition, the disaggregate framework is useful for debugging, calibrating, and refining model sensitivity. Simulation Variation A concern frequently expressed about detailed demand and supply microsimulation models is that of random simulation variation. On the demand side, simulation variation can result from the Monte Carlo simulation methodology used to convert the probabilities in the model system to discrete choices. How- ever, the DaySim software has been implemented in a way that reduces simulation variation by holding the random number seeds and sequences used in the model system fixed across iterations. As a result, the changes between alternatives reflect only the changes in the probabilities for individual choices, not for the simulation method itself. On the supply side, simulation variation proved to be somewhat more complicated because of the dynamic nature of the network microsimulation. The network assignment methodology involves the iterative simulation of demand and feedback of network performance measures. Because the network simulation model is sensitive to even small-scale changes, significant and sometimes problem- atic variation in network performance can result from one assignment iteration to the next. To address this variation, the project team tested a number of assignment configurations and selected one that produced the most stable results. This configu- ration produced relative gaps and other stability measures that, while achieving a level of convergence comparable to a static assignment model, produced results that allowed the project team to distinguish between alternatives. The project exten- sively investigated how many assignment and model system iterations were required to produce outputs in which the differ- ences between alternatives were truly attributable to the alterna- tives and not to noise within the model system. Extracting, Managing, and Interpreting Results Extracting, managing, and interpreting these results from the model system is not difficult. Much of the network perfor- mance data that is of primary interest is available in link-based

133 text files that can be easily processed. Similarly, the travel demand outputs of the model system are also easily interpre- table, mirroring the structure of a typical household travel survey. Of course, given the detailed nature of the model system, the files can be quite large. In addition to supporting much more targeted analyses, another advantage of the detailed data produced by the model system is that it can be used to develop visualizations. A number of tools have been developed for TRANSIMS that provide visualizations of second-by- second vehicle movements on the regional networks, cap- ture network performance “heat plots” of congestion, and provide other visualizations as well. These visualizations are not only effective for conveying model results to decision mak- ers but are also essential tools for debugging the model system performance. Conclusions The new model system is more sensitive to a wider range of policies than a traditional travel demand model system; this sensitivity is further enhanced by the detailed representation of temporal dimension, as well as the increased behavioral and spatial detail. In addition, the model system produces a wider range of statistics of interest to decision makers. Extracting, managing, and interpreting these results was not difficult; how- ever, the level of effort required to effectively test different types of improvements varied widely, from as little as an hour to more than a week. Using the model to evaluate pricing and TDM sce- narios was relatively easy, requiring straightforward adjust- ments to network coding or to model coefficients. Using the model to evaluate the operational scenarios required signifi- cantly more effort because of the sensitivity of the network simulation to different signal coordination and timing assump- tions. This level of effort would undoubtedly increase if more extensive changes to operational assumptions were required. In addition, even with the additional effort, the results produced by the model system did not seem as intuitive as the results of the other scenario tests. Random simulation variation did not compromise the abil- ity to use the model system, provided a sufficient degree of con- vergence was achieved both within the network assignment and for the model system overall.