Traffic Model Extended

(By Forrest Sondahl, 2005)

The applet requires Java 1.4.1 or higher. It will not run on Windows 95 or Mac OS 8 or 9. Mac users must have OS X 10.2.6 or higher and use a browser that supports Java 1.4. (Safari works, IE does not. Mac OS X comes with Safari. Open Safari and set it as your default web browser under Safari/Preferences/General.) On other operating systems, you may obtain the latest Java plugin from Sun's Java site.

Created with NetLogo * View/download model file: hw2-forrest.nlogo * View the documentation for this model



Analysis

While it is interesting and entertaining to play around with the sliders for the number of cars, and their acceleration and deceleration constants, let us consider the practical implications of this model. If we were transportation engineers or policy-makers in a city, attempting to alleviate the traffic jams that plague certain roads, we would have little control over these variables. Our options instead might include some of the following: changing the speed limit on the road or adding more lanes to the road. So I extended the model to allow for these changes, and examined its behavior under various conditions. I also suspected that the perfect wave-forms given by the original model were not representative of cars “in the wild.” That is, after the initial random placement of the cars, each car's actions were governed by purely deterministic rules from that point on. So I added an option to turn on or off some degree of randomness in the acceleration pattern.

Part 1: Speed Limits

The first part of my analysis centers around “speed limits”. (Although the original model did not include a slider to change the maximum speed limit for all of the cars, the change from making “speed-limit” a global slider variable instead of a turtle-owned variable may be considered trivial.)

It was my hunch that lowering the speed limit could result in less traffic jamming, and even possibly result in greater throughput for all the cars on the highway. First, I needed a metric to measure throughput. Instead of summing up the total distance traveled by all cars, or the number of cars passing a certain point in one minute, I decided to simply use the average speed of the red car since it should be indicative of the overall speed of all the cars.

The results of varying the speed limit using the original model with default settings (cars: 20, speed-up: 45, slow-down: 26) are displayed here.




I ran 20 repetitions for each speed ranging from 1 to 100 mph, in increments of one unit (it took almost an hour and a half!). I was hoping that averaging the results of the 20 runs for each speed would yield a fairly smooth graph, but I was disappointed. The jerky nature of the graph comes from the fact that in any given run, either the traffic begins to flow smoothly at the speed limit, or it forms a jamming pattern in which the cars all move quite slowly (usually around 24 mph). As the speed limit gets higher, the probability of jamming increases, but counterbalancing that is the fact that each car gets to move faster if no jam forms. As seen in the diagram above, the benefit of a higher speed limit outweighs the increased likelihood of jamming, in terms of overall average car speed (we are not considering the increased probability of accidents incurred by higher driving speeds, etc).

Though this result contradicted my original intuition that a lower speed limit might actually increase throughput, I was willing to accept this result. Almost. As I noted above, there was something bothering me about the deterministic nature of the model. That the cars would all speed up uniformly, and maintain the maximum speed limit perfectly. It didn't match with my conception of driving in real life, where people “randomly” speed up or slow down based on various conditions (although one could argue that with cruise control, they can maintain the maximum speed limit quite accurately). It also annoyed me that once a traffic jam had formed, there was no way for it to break up. Conversely, once traffic started flowing smoothly, no jams would form. These patterns were too perfect, and the graphs too symmetric. So I added in a random factor. When there are no cars in front of you, change your speed by as much as 5% up or down (but more often 0-2%):

if (randomness? and (not (any? turtles-at 1 0)))
[set speed (speed * (100 + random 5 - random 5) / 100.0)]

(This option may be turned on or off in the model by the randomness? toggle). With randomness in effect, the traffic jams still form wave patterns as before, but the wave can change or disappear, and new jam waves can form. I decided to run the speed limit test again, with randomness, and here is the resulting graph:




This time I was pleased to discover that my intuition was correct. That is to say, if this model accurately reflects how drivers act (which is thoroughly debatable), then reducing the speed limit to a certain point will yield better traffic flow and everyone will go faster overall. I was, honestly, quite thrilled with this result. In some ways this result seems counter-intuitive: I am sure that many people would refuse to believe me if I told them that making the speed limit lower could allow everyone to go faster. But through an understanding of the various levels of an emergent pattern, it makes sense.

Part 2: Lanes

I have to admit that I haven't had a chance to do in-depth analysis of the effect of multiple lanes on the model. Thus, I will mainly clarify the new rules that the agents are working with in a multi-lane environment, and present some very preliminary findings.

Essentially, the rules that have been added are:

If there is a car in front of you:

Where lane is open means “there is no car directly to the side of you, and there is no car in the spot in front of that.”

During setup, cars are placed randomly spread across the open lanes.

Findings: In this case, it was my intuition that having two lanes of traffic should more than double the throughput capacity of the road, on account of the added flexibility. I set out to test this hypothesis with BehaviorSpace.

Cars
 Lanes
 Avg. Speed
10
 1
 90.83
20
 2
 94.42
40
 4
 94.96



20
 1
 24.78
40
 2
 23.99
80
 4
 22.89



15
 1
 62.5
30
 2
 60.76
60
 4
 56.25



30
 1
 11.12
60
 2
 11.06
120
 4
 10.68

Although each of the lines above represents an average across the results of 20 repetitions, the results are inconclusive. If anything, they reject my hypothesis, rather than confirm it. The first set (10, 20, 40) shows some speed increase, when doubling the cars and the lanes. However, the other three sets all show a downward trend in average speed with more lanes. I have not yet satisfactorily accounted for this. The best explanation I can muster is that when a traffic jam starts to form in either lane, it causes one of the cars sitting slowly in the jam to switch lanes, which immediately clogs the other lane and causes a jam there as well. Thus if either lane jams, then both jam. This is, however, mostly speculation. Further investigation of this phenomenon is recommended; if it continues to show diminishing returns for added lanes, then we must either question my original intuition about added flexibility, or we must question the rules of the simulation.

Back to Forrest's NetLogo Main Page.