EXPERIENCES WITH TRANSIMS (VERSION 1.0)

Before programming our own modules as explained above, we attempted to use TRANSIMS. The TRANSIMSthat we used is numbered 1.0 and was made available in fall 1999. Our experiences were as follows:

Porting TRANSIMSour own computational environment was straightforward. Using our own input files was relatively straightforward, but hindered by the fact that errors in input files - such as a forgotten tab - caused the simulation to crash without a meaningful error message. In consequence, one had to find the cause of the problem via manual trial and error.

Computational speed of the microsimulation without tuning was ten times faster than real time for our Swiss network with 28622 links; with tuning it was about 65 times faster than real time. Both values refer to a Beowulf clusters with 32 Pentium CPUs with 800 MHz, and 100 Mbit Ethernet. The latter performance value is about half the theoretical limit, which is given by Ethernet latency (28,11).

A major problem was (and is) the availability and conversion of digitally available input data that meets TRANSIMS's needs. As is typical, our input files come from static assignment, and thus contain as link attributes length, free speed, and capacity. The number of lanes can be inferred from the street category and capacity, but information such as intersection prioritization, signal phases, or lane connectivity, were missing. A typical problem is of the type that two one-lane streets, connecting into a two-lane street, will both connect into the same lane, leading to much reduced capacity and thus spurious bottlenecks when compared to reality or to static assignment. According to recent information (Lamba, at PriceWaterhouseCoopers, personal communcation), such conversion tools exist for newer versions of TRANSIMS. Also, PTV (25) reports similar conversion tools from VISUM to VISSIM.

Using routing and feedback was essentially straightforward, except for the fact that the results of the Gotthard scenario never were plausible: Contrary to expectation, the different queues leading to the single destination never came close to equilibration (Fig. 5). It was finally discovered that there was a bug in the way link travel time feedback was handled: the link travel time reporting allocated the times to the wrong links. More technically, indices were shifted by one in the process, and so travel times for the $n$th link in the file were assigned to the $n\!+\!1$st link in the router. Personal communication with the TRANSIMSresulted in the information that there were more bugs in the router both in version 1.0 and in version 1.1. Version 3.0 now available (www.transims.net) has not been evaluated in the context of this study.

Abbildung: TRANSIMS Results for the Gotthard Scenario. TOP: Initial iteration. BOTTOM: After 50 iterations. This should be compared to Fig. 2. The visible differences between the TRANSIMS simulation and our queue simulation in the initial simulation based on the same plans are small (TOP in both figures), indicating that the micro-simulations generate similar traffic patterns. However, the bottom figures are rather different; traffic in Fig. 2 spreads out much more across the network. Further analysis of the pattern shows that Fig. 2 contains the better pattern in the sense that travel times between different routes are much more equilibrated. As described in the text, the reason why TRANSIMS (Version 1.0) fails at this scenario is because of a bug in how the router reads link travel times. The different shades of green (color version) or gray are due to the different internal representation of driving dynamics between the TRANSIMS micro-simulation and the queue simulation, and are not important at this level.