aaa---sotl.nlogo

NETLOGO

1
1
timesteps

BUTTON
132
257
206
290
Refresh Plots
clear-all-plots
NIL
1
T
OBSERVER
T
NIL

SLIDER
4
187
176
220
tolerance
tolerance
1
300
41
1
1
cars * timesteps

BUTTON
64
257
126
290
ResetTL
reset-traffic-lights
NIL
1
T
OBSERVER
T
NIL

SLIDER
156
46
261
79
%vertical
%vertical
0
100
50
1
1
%

SLIDER
3
222
176
255
metatolerance
metatolerance
0
10
0
1
1
tolerances

SWITCH
101
82
191
115
yellow?
yellow?
0
1
-1000

CHOOSER
179
210
282
255
control
control
"marching" "optim" "cut-off" "sotl-request" "sotl-phase" "sotl-platoon" "no-corr"
5

SLIDER
102
153
230
186
mingreen
mingreen
0
50
20
1
1
timesteps

SWITCH
202
10
292
43
torus?
torus?
0
1
-1000

MONITOR
419
237
476
286
cars
count turtles
0
1

PLOT
281
290
481
440
Number of Cars
Time
cars
0.0
100.0
0.0
100.0
true
false
PENS
"default" 1.0 0 -2674135 true
"global" 1.0 0 -16777216 true

SWITCH
295
10
393
43
four-dirs?
four-dirs?
1
1
-1000

SLIDER
263
47
370
80
%southbound
%southbound
0
100
50
1
1
NIL

SLIDER
373
46
472
79
%eastbound
%eastbound
0
100
50
1
1
NIL

SWITCH
291
450
394
483
plots?
plots?
0
1
-1000

MONITOR
360
237
417
286
NIL
clock
3
1

SLIDER
287
82
393
115
prob-turn
prob-turn
0
1
0.0
0.01
1
NIL

SLIDER
232
153
366
186
keep-platoon
keep-platoon
0
10
5
1
1
patches

SLIDER
367
153
491
186
cut-platoon
cut-platoon
0
10
3
1
1
cars

SLIDER
287
189
394
222
queue-cut
queue-cut
1
10
3
1
1
cars

SWITCH
395
10
485
43
homo?
homo?
0
1
-1000

@#$#@#$#@
WHAT IS IT?
-----------
This simulation was exended from the model "Gridlock" by Uri Wilensky & Walter Stroup, which comes with NetLogo 2.0.0 (see more info at the bottom)
Traffic lights try to "self-organize" for improving traffic.

Traffic is not so much an optimization problem, but an adaptation problem, since traffic flows and densities change constantly. Optimization gives the best possible solution for a given configuration. But since in real traffic the configuration is constantly changing, it seems that we would do better with an adaptive mechanism than a mechanism which is optimal some times, and some times creates havoc (and it is too expensive to try to find all possible optimal solutions, since the configuration space is too huge and uncertain...). 

NOTES:
------

+ Only q's are quite adaptive, but do not generate "excessive" synchronization... what occurs is that "convoys" are formed, which can pass much faster at intersections, and in turn leave space for other convoys... but resetting T.L. does not create much difference... 

+ By mistake, Working with "wrong" parameters (non integer pg's): it switches traffic light ONLY when "tolerance" is reached. Light changes only by "request", but no actual internal clock... In any case, through stigmergy, cars self-organize... It actually seems to perform better:
	+It turns out that when the lights change by themselves, the algorithm is not
	as good... (changes when noone needs it)
	+Then only one parameter to deal with: tolerance

+ Adjusment of pg's (metatolerance > 0) decreases the performance of self-org... (too many attempts to self-org can cause noise... similar to overfitting in ANN's???)

+ different "tolerance" & p good for different densities? (shape the size of "convoys")

+ std deviations of speed & waiting cars increase probability of traffic jam... self-org strategies have much less std. devs...

+ for medium traffic density (100 cars) and several streets (9x9), sotl-request works better (this should be chosen if too much noise will affect the return of cars... since real cities are not toroidal, probably this would be a better option for implementation...). Also to reduce the tolerance improves performance (e.g. 18 cars*ts). For higher density (200 cars) both sotl request and phase similar... For very high density (300 cars), phase better than request. If tolerance is higher, then request better... Long platoons (convoys) can promote traffic jams... good to have them, but not too long... High traffic density will give long platoons no matter what, but sotl-request seems to be better at keeping them short.
For few streets (3x3) sotl-phase seems to be best. For higher densities request needs higher tolerance in order to work properly, but sotl-phase works fine with different densities and same tolerance...

+ With very high traffic density, sotl-phase behaves almost as marching, which is ok to avoid traffic jams... Higher tolerance or mingreen might be better for this method in high density... (Marching is best strategy to avoid deadlocks for very high traffic density (>300,400,600 cars in 5x5)). For these densities, more waiting times and stopped cars give more average speed, because of reaction times.

+ self-org platoons observed of 3<=cars<=15, for tolerance=41, p=43, cars=74, 5x4, 81x81 patches. It depends on distance between intersections and tolerance

+ %vertical seems not to affect much the avgs. of static strategies, but sotl improve, performance slightly, especially sotl-request, and this increases with the extremity of %vertical

+ optim is "designed" for optimizing south+eastbound traffic. The difference of all traffic goind SE vs. all going NW is less than 0.1 ptch/ts avg.

+sotl-phase also reaches full synch in 4-dir+torus

+sotl-platoon better at low densities -> more robust full synch, but gets more quickly into traffic jams...

+main idea: should keep platoons nor too short nor too long... and as stable as possible...

TODO's:
-------

-prioritary vehicles: add weights to cars in sotl methods for kappas, override in other methods...
-make proper non-homo streets... cloc!
-could do different strategies per intersection, to compare the effect of one self-org in a meching system, or a marhcing in a s-o.s.... (how much noise would this last case propagate? Similar to faulty intersection...)
-something really nasty goes on with metatolerance>0...
-do "forgetting" of lambdas and kappas (~forgetting)
-try to reach some general adaptive synchronization: this seems to be required in order to avoid traffic jams when traffic is dense... well, the "request" model does that...
-bug when 2dirs are created BEFORE a setup of 4dirs is run. Crappy temporal solution: do a setup of 4dirs, then play with 2dirs

CHANGELOG:
----------

1.04	2005-12-06	Added lookahead to sotl-platoon... works a bit, but traffic
                        jams still occur when cars stop blocking other streets...
1.03	2005-08-24	Fixed maxspeed bug...
1.02	2005-08-24	Maxgreen try (didn't work)
1.01	2005-02-22	non-homo streets (beta), sotl still rule, full synch & 					everything...
1.00	2005-02-02	completed Information on how to use it....
0.23	2005-01-24	tested with faulty interesections, no big difference for any 				method...
0.22	2005-01-19	added cut-off method (so so...)
0.21	2004-12-10	added cut-platoon slider... sotl-platoon not good for high 				densities...
0.20	2004-11-28	improved sotl-platoon method, now better for high densities...
0.19	2004-11-28	added sotl-platoon method, get more robust full synch...
0.18	2004-11-24	added no-corr method
0.17	2004-11-22	added avgCars in graph
0.16	2004-11-17	changed to 10x10 grid
0.15	2004-10-13	implemented turns
			implemented plots? switch
0.14	2004-10-12	fixed initial %'s
0.13	2004-10-12	implemented 4 dirs. sotl rules!
0.12	2004-10-12	adjusted non-torus to include %vertical
0.11	2004-10-11	non-torus implemented. sotl strategies still better
0.10	2004-10-11	moved interesections a bit, begining to implement non-torus
0.09	2004-10-07	Did first stats, found full synch, fixed bug of yellow lights 				in ResetTL
0.08	2004-06-16	???
0.07	2004-06-15	Added "optim" strategy: it sucks! it's crap! worse than march
			Fixed sotl-request (sotl-phase with mingreen works bit better)
0.06	2004-06-08	Added switch for different control strategies (now marching, 					sotl-request, sotl-phase (last better))
			Added mingreen, not to have constant changes of lights, seems 					to work good.
0.05	2004-06-04	Added means to plot, shows more clearly that SOTL work better 					than half on, half off.... need to compare with real 					control techniques 
0.04	2004-03-30	fixed some bugs... it wasn't working properly
			(previous bugs turned out to be features...)
0.03	2004-03-29	added lambdas and adjustment of pg's
			fixed yellow-light bug (no change of q when yellow-light?)
0.02	2004-03-26	added yellow lights
			added %vertical for different traffic densities
0.01	2004-03-22	included pg1 and pg2 for different lights 
			added kappas and adjustment of q
			already does better than "all on or off"
0.00	2004-03-22	just removed Hubnet functions


HOW TO USE IT
-------------
QUICKSTART INSTRUCTIONS:
------------------------

Run "Setup" before starting simulation. Then start and stop with "Go". Some parameters, such as grid-sizes and four-dirs? will be applied only after pressing "Setup".

Tip: you can "freeze" the display (on top of the "city" display) and/or switch off the plots to accelerate simulations.

For model details, consult the paper "Self-Organizing Traffic Lights" http://uk.arxiv.org/abs/nlin.AO/0411066

BUTTONS:
--------

"Setup"- Initializes simulation

"Re-run"- "soft" and quick "Setup" (just clears variables, doesn't change street topology)

"Reset-TL"- Turns phases of adaptive control methods ("sotl"'s and "cut-off") to zero, so that they need to adapt again (to check robustness)

"Go"- Start and stop simulation

CHOOSERS:
--------

-control- select control method for traffic lights
+when changing methods during the same run, resetTL. (If one was yellow, can cause problems...)

SLIDERS:
--------

"grid-size-x"- number of vertical streets

"grid-size-y"- number of horizontal streets

"number"- initial number of cars for "Setup" and "Re-run", maximum number of cars when torus? is off

%vertical- percentage of cars flowing in vertical roads (%horizontal= 100-%vertical)

%southbound- percentage of cars flowing in southbound roads (%northbound= 100-%southbound)

%eastbound- percentage of cars flowing in eastbound roads (%westbound= 100-%eastbound)

prob-turn- probability of turning at an intersection

simulation-speed- regulates processing speed

speed-limit- maximum speed of cars

p- phase period for cyclic control methods ("marching", "optim", and "no-corr")

mingreen- minimum green phase for "sotl-phase" and "sotl-platoon" controls

keep-platoon- "omega" distance at which carsh are checked from green light in "sotl-platoon" control

cut-platoon- "miu" cars approaching a green light at which platoons can be cut in "sotl-platoon" control

queue-cut- lambda queue length for "cut-off" control

tolerance- "theta" threshold for all "sotl" control methods

metatolerance- attempt of metaadaptive regime. Doesn't work, keep set to zero...

SWITCHES:
---------

torus?- switches cyclic boundaries on and off

four-dirs?- toggle between two and four directions (needs "Setup")

homo?- toggle between homogeneous and heterogeneous street distances (needs "Setup")
     -works nicely for 8x8

power?- makes traffic lights work

yellow?- include yellow phase (1 timestep) between green and red phases

crash?- monitor crashes at intersections

plots?- switches plotting (off increases simulation speed)


CREDITS AND REFERENCES OF ORIGINAL "GRIDLOCK"
----------------------
This activity and associated models and materials was created as part of the projects:
PARTICIPATORY SIMULATIONS: NETWORK-BASED DESIGN FOR SYSTEMS LEARNING IN CLASSROOMS and INTEGRATED SIMULATION AND MODELING ENVIRONMENT. These projects gratefully acknowledge the support of the National Science Foundation (REPP & ROLE programs) -- grant numbers REC #9814682 and REC-0126227.

Copyright 2002 by Uri Wilensky & Walter Stroup. All rights reserved. 

Permission to use, modify or redistribute this model is hereby granted, provided that both of the following requirements are followed: 
a) this copyright notice is included. 
b) this model will not be redistributed for profit without permission from the copyright holders. 
Contact the copyright holders for appropriate licenses for redistribution for profit. 

To refer to this model in academic publications, please use: Wilensky, U. & Stroup, W. (2002). NetLogo HubNet Gridlock model. http://ccl.northwestern.edu/netlogo/models/HubNetGridlock.  Center for Connected Learning and Computer-Based Modeling, Northwestern University, Evanston, IL. 

In other publications, please use: Copyright 2002 by Uri Wilensky and Walter Stroup.  All rights reserved.  See http://ccl.northwestern.edu/netlogo/models/HubNetGridlock for terms of use.
@#$#@#$#@
default
true
0
Polygon -7500403 true true 150 5 40 250 150 205 260 250

car
true
15
Circle -1 false true 185 55 60
Circle -1 false true 183 186 61
Polygon -1 true true 214 52 214 22 182 26 162 38 144 74 138 102 100 120 99 161 102 201 118 246 152 267 190 275 210 251 187 240 178 200 204 182 215 181 214 118 193 112 182 98 181 72 198 52

@#$#@#$#@
NetLogo 3.0
@#$#@#$#@
@#$#@#$#@
@#$#@#$#@
@#$#@#$#@