Successful Compile, Whats Next?

This afternoon I successfully compiled my model, all of the code is posted on my repository for you to look at, however it is not quite finished.  I still have to write a small function to generate a map, there should be examples of this function somewhere on the ROSS website.

So far I have forward event handling completed however I will not be able to test it until I have written the map generator.  This should be done hopefully before the end of the weekend and I hope to have a serial test done before next Tuesday.  Once this is done, I will write the reverse event handler which should be much easier than the forward event handler and run my parallel tests.

Hopefully I will be able to test my model in parallel before next Friday so I will have some results to present.  Overall there doesn't seem to bee a while lot of coding left to do before I am able to begin analyzing results.

--J

Using Lanes to Determine Traffic Flow

Since The last post I have included the concept of lanes to direct traffic because it is more realistic and will make the results of tests more accurate.  I will explain how this works through an example.

The concept of lanes is evaluated during the execution of the DIRECTION_SELECT event.  At the beginning of the event, the car is in the lane represented by the blue arrow, and came from the arrow represented by the red arrow.  The blue arrow represents the incoming right turning lane on the east side of intersection 1.  Because the blue lane is a right turning lane, the car can only go either north or back east, the objective of DIRECTION_SELECT is to determine which of the north three lanes the car wishes to enter or sending the car back east.  To choose one of the outgoing north lanes, the event first checks if the car wants to go north or south to get to its destination, if it wishes to go north and the center green north lane is free, it will enter that lane, the same is true for the left and right turning lanes.  If the car however cannot enter either of these three lanes going north it will be sent back east to simulate a traffic jam.  To determine which lane the car enters of the three outgoing east lanes, the event must determine how the car arrived at the previous intersection (intersection 2) this is to ensure that there is not an excess of cars in any lane.  The orange arrows represent the possible ways the car arrived at intersection 2 and by determining which of these was true, the car is placed in the appropriate outgoing lane to send the car back in the direction it came from.

The next step in coding is to code the reverse event handler which is used to "undo" events when rollbacks occur, this should bee done by the end of the week.

I figured out how to push code!

The code that I have pushed today is a framework of how my model will work.  Unless I can figure out a better way compatible with ROSS, I will probably end up using the huge set of switches that you see in the event handler.

Another added item that was not discussed in my previous blog posts is lanes.  As you can see I have included data for relative directions (left turning land, right turning land, and straight) and cardinal directions for the roads adjacent to a particular intersection (north, south, east, and west).  This allows for a few things that improve the accuracy of my model.  The first improvement is more traffic through intersections, most intersections and roads have more than one lane, especially in a large city.  In addition, this allows for a sort of one step pre-calculation of direction meaning that by the time the car gets to the center of the intersection, the cardinal direction it will move in is already determined and it just needs to select which lane it will enter (left, straight, or right), which is more realistic than one lane intersections.  The introduction of lanes makes u turns a little harder though because it is unclear which lane a car would go into when it turns around (left, right, or straight), I think the car will go into the lane that would lead to the intersection it came from, however this may be hard to calculate.

Hopefully by the end of this week my model will be done (if I don't run into any major problems) and I will have some test results to post.

--J

Event Flow Chart and Avoiding Jams

I have drawn up three diagrams to explain some of my the topics covered in my last post better.

This is a diagram of two intersection nodes. Suppose a car needed to get from intersection 2 to the intersection that is west of intersection 1; we will also suppose that the number of time steps required to get from the end of an incoming queue to the center of an intersection and the number of time steps required to get from the center of the intersection to the front of the outgoing queue, is 5. The car would exit the west outgoing queue of intersection 2 and enter the incoming queue of intersection 1 which would schedule a choose direction event for 5 time steps in the future. When the car got to the center of intersection 1 (this is represented by the execution of the choose direction event), it would realize that there was no room to enter the west outgoing queue, or any other queue for that matter, so the car would schedule a departure event to go east for 5 time steps in the future, which would put the car in the east outgoing queue of intersection 1. It would also schedule an arrival event for intersection 2 for the 5 time steps in the future. This cycle may go on once or twice in hopes that one of the jams in intersection 2 will subside. However, if the jams do not subside, the car will have to choose a different direction to avoid the jams. 

This is a diagram of many intersection nodes all in a configuration and how the previously described algorithm can be used to avoid a jam, as well as how to avoid a livelock for the entire model. The car will begin by attempting to go south the east, after a few tries it will go either west or north (west in this case) and then go south. The car will then try to go east again when it is nearest to its destination, and when it realizes that it cant, it will go south again, then east and then north. A car's final destination is determined by the total number of spaces north or south and east or west, it has remaining to move. Therefore the algorithm to determine where the car should move from a particular intersection becomes very simple, the car should either towards its destination in the vertical or horizontal directions. If neither of these two options are available, the car must pick a different direction at random and move there in an attempt to avoid the jam.

The flow chart above describes the events that are scheduled in order to accomplish the algorithm aforementioned. The colors indicate which intersection to the particular event is scheduled for, and the arrows indicate which event (and intersection) the even was scheduled by. Starting at the event indicated "start", the arrival event schedules a direction choice which schedules a departure. An arrival is then scheduled on the blue intersection which goes through the same process as the red intersection and sends the car back. This may happen a few times before the red intersection schedules an event to send the car to a different intersection. 

I hope to have this coded up by next week, and if all goes well I should have some performance results within the next two weeks.

-J

This weekend I will be...

Over the past couple of weeks I have done a lot of work on ROSS Vehicular Traffic Model, one of the problems I am having is putting my work into a format that is easily sharable with the rest of the world because a lot of the work I have so far consists of diagrams and flow charts that I have drawn in my notebook.  This weekend I will be uploading all of the diagrams and flow charts I have made that describe how my model works and explain what problems I ran into.

I have also spent the past few weeks learning how to use ROSS and how to write a model in code.  Unfortunately there is not as much documentation as I would have liked on ROSS and it is hard to find people really know how it works.  Professor Carothers and Thomas "TJ" Reale have been a great resource in helping me understand how ROSS works and how constructing a model works.  Here is a link to a basic ROSS model with some instructions on how it works.  http://odin.cs.rpi.edu/ross/index.php/Constructing_the_Model

Today I committed code that I wrote about a week and a half ago (so you can get an idea of what it will look like) before I realized that I needed to go back and redo some parts of my model (which I will explain in a blog post later this weekend).  Also thanks to Peter Hajas for helping me with git hub.

The rest of this blog post will be dedicated to describing some restrictions when using optimistic simulation and ROSS that have been challenges.

• ROSS is an event based simulator, thus every action that you wish to perform must be modeled in this way.  An event consists of a set of code that will be run and usually consists of the following: some form of statistical record keeping, a manipulation of local data, and the scheduling of a future event.  For example, if a car arrives at an intersection the node will execute an ARRIVAL event: a counter for the total amount of cars at that intersection will be incremented, a car object will be entered into the incoming road queue, and a DEPARTURE event with a time stamp of some time in the future when we think the care will be able to depart.  This limits how a model can be constructed, and this will become evident in future blog posts.
• As I have described in my presentation, my traffic model will essentially be a set of intersections, each intersection being its own node.  When using ROSS, it is impossible for nodes to share information, thus they must send information to each other in the form of an event.  This is a huge problem in regards to a DEPARTURE event because it is impossible to instantly check if the roadway of a neighboring intersection is clear (there are few enough cars on that road so that there is enough space for the car of interest to enter it).  My initial solution was to have neighboring intersections schedule events for the intersection of interest telling it when it becomes free and when it becomes jammed.  This solution however would cause huge problem with the optimistic part of the simulation because the time stamp on that event would have to be 0 (instant).  This is a problem because by the time the intersection processes that event, the time simulation would have already passed that event's time stamp which would cause a rollback which is very inefficient.  My new solution to this problem (which will work) is as follows.  All intersections will have two (well, more than two but more on that later) queues in all four cardinal directions, one for incoming traffic and one for outgoing traffic.  When there is an ARRIVAL event, a car will be pushed into the incoming queue and will progressively make its way to the center of the intersection.  When it gets there it will attempt to join the outgoing queue in whatever direction it desires to go (more on how that works later too).  If that queue is full, the car will go into the outgoing queue in the direction it came.  Because of this, a DEPARTURE event will not have to check to see if the roadway is clear because no matter what, a car will be popped off the front of the incoming queue (if there are any cars in the incoming queue) making room for any cars coming from other intersections.  This solution does however present ways for my model to "livelock" which I have also found a good solution for which I will explain in a later post.

This project has been very interesting to work on so far because the fact that most of the code (ROSS) has already been written and most of the focus is on the design of the model.  I expect that once I have the final details of my model ironed out, coding up the model shouldn't take more than a few days.

If you have any questions for me or would like me to explain anything better in my post, feel free to contact me at schnej7@rpi.edu .

-J

Progress on Model Construction

I have been working on my model construction over the past few weeks.  It has proven to be much more difficult that I initially anticipated due to the lack of documentation and the unique and specific format of the model.  I have code to push, but I am currently having trouble with github which I hope will be fixed later today. I still need to iron out some of my events before I begin testing my model, but I think I am close to having a testable version.

-J