A Simple Discrete-Event Simulation: Part 42

Today I replumbed the layout of components to include a single entry, a single queue, and two processes that each feed the single exit. This required the following modifications:

• The Queue component had to support multiple outgoing paths.
• The Queue component had to be able to alternate sending entities forward along the various outgoing paths, subject to the next (Process) component being open and available. In practice what this means is that when an entity reaches the front of the queue it increments the counter for the most recently-used path. It then checks to see if that path is open and if not, it continues to increment (possibly wrapping around to the first path) and test until an opening is found or all paths have been tested. This ensures that entities are forwarded uniformly to the connected downstream processes, subject to variations in the time it takes to process the entities in the downstream process components. This mechanism is appropriate when a queue is feeding multiple components of the same type, which should always be the case. If a component supporting multiple output paths is meant to direct entities to downstream components of differing types then a routing mechanism should be used that is driven by the logic of the process. We saw the mechanics of this idea yesterday as entities were routed from the Arrival component to the different Entry components based on assigned percentages.
• The Queue component now incorporates the concept of a minimum transit time. When an entity enters a Queue it initiates a discrete-event timing event, and when that event is picked off the future events queue we know the entity is available to be forwarded. The Queue component attempts to forward the entity as described above and, if cannot do so, it waits until one of the downstream processes calls back to pull an entity from the Queue.
• The logic for determining whether downstream components are open or upstream components have entities available to pull may have to consider the status of the path that connects the downstream or upstream component to the current component. Whether or not this complication has to be considered depends on whether the path has been marked as exclusive. Non-exclusive paths are connected to downstream entities that are defined to always be able to receive entities (e.g., the Queue and Exit components, and technically the Entry components and non-exclusive Path components–so far). Components can only forward entities along exclusive paths if the downstream Path component is empty and the downstream connected (Process) component is open. Components retrieving entities from upstream through a connected path (which should only be possible along an exclusive Path component) have to request the previousComponent.previousComponent‘s forwardEntity method to pull an entity forward.
• I tweaked the timing of the various components a little bit and added two more 30-minute time intervals to the end of the run, during which no new arrivals are generated. I did this to ensure that the simulation would always clear.

Here’s the model as it has been updated and configured.

I’ll skip the listings for the modified components today, since they need to be cleaned up a bit, but I will include the updated code for initializing everything.

This took longer than I expected today so I’m also going to forego implementing the capability to reset without refreshing the browser page.

Tomorrow I’ll try to get that done and see if I can’t streamline and automate a few mechanisms and definitions. I’ll also make the display smaller by cutting some of the display information out of the component visuals, now that we know things are working. Things are getting a bit unwieldy here and need to be cleaned up!