A Simple Discrete-Event Simulation: Part 40

Today I modified the framework to define Node components separately from Path components. This allows us to have any number of paths going into or out of any node so that any arbitrary network can be defined. In the code’s current state components that are not nodes or paths can hand entities off to other components that also aren’t nodes or paths, or to nodes. Nodes can hand entities off to paths or to components that aren’t nodes or paths. Paths can on receive entities from nodes and hand entities off to nodes.

This is actually a little bit awkward, and we are on a bridge between two versions of what this kind of discrete-event simulation model can be. One version is more abstract and considers only how entities move from component to component. It might not be very interesting visually, but it would be very fast and would get the job done as far as performing the desired analysis. The other version is more detailed and would effectively do away with all components that are not nodes or paths. In this version the process activities would take place at nodes and queues would form wherever nodes backed up behind processes. That can make it a bit trickier to figure out when an entity entered a given queue but that’s just a technicality.

The more detailed version is much more complex to write and debug and takes more memory and execution time (potentially by a lot) but if way more visually interesting. Observers can see exactly what’s going on inside the model as it runs (or as a run is replayed). For the time being I’m going to back up and finish building out the more abstract version. To give it some visual interest, however, I will retain the visual paths between components so users can get more of a feel for where entities are being sent in a simulation. I might back the representation of the nodes and paths to the earlier version where I defined paths with nodes included on each end, and ensure that I never include more than one path between components (if possible).

There’s a lot that can be done with a more abstract version of this tool and I have an interesting in getting something more interesting running and usable. I plan to do the more interesting and detailed version going forward, and that will involve finding detailed solutions to the problems of entities competing to pass through intersections, as has been discussed over the last couple of days. I think it’ll be helpful to build that kind of framework and play around with it rather than try to whiteboard everything up front where it’s hard to follow what might be going on.

In the meantime here is the code for the new Node component. Notice that there are currently no discrete-event handling mechanisms in this version. When a component (path or otherwise) hands an entity off to the node it immediately gets forwarded to the next component. This may not be enough in the long run, but it works well enough in my test case so it is sufficient for now. The node can be connected to one or more paths or a single non-path component either coming in or going out, so the node figures out the kind of forwarding or receiving to do be checking against the number of incoming or outgoing paths that are linked to the node. Also, when the end of a path is assigned to a node the assignment causes some relevant values to be assigned within the path component.

Here’s the updated code for the Path components. It is almost untouched from its previous version.

Here’s the new code that initializes everything.

It doesn’t look any different than it did before, and it still works, so that’s always good!