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