R.P. Churchill.com

Today I went through and cleaned up each of the component definitions in the process of implementing the ability to rerun the simulation without having to refresh the browser page. Beyond just neatening up the code for each component I added a reset function which resets all of its state properties but leaves the established configuration properties (definition, layout, and linking) in place. The reset function then just has to cycle through each component in the listOfComponents array and call the reset function for each. I can then just reset the discrete-event timing mechanisms and a handful of other global control/state variables (which should ultimately be given their own namespace and separate file). The global timing mechanisms and control variables should be reset before the list of components, since resetting the components sometimes refers to the global values (mostly the global simulation clock).

Here’s the snippet that gets executed when the Reset button is clicked, along with one example of a reset method in a component object. As a side note I found it interesting that the parameters to the JavaScript closure constructors are always available, like that’s just another way of declaring an internal member property. I’m sure I’ve made use of this effect previously, but the awareness just became conscious.

I made sure the components were all drawn once the system was initialized and when it is reset, so they’re visible before the simulation starts running. I’m thinking I’ll want to split the drawing of paths up so that the lines are drawn with all of the other objects and then the nodes and entities are drawn separately and later, so nodes always sit on top of both components and entities always sit on top of components and nodes.

I also noticed that certain aspects of the Queue component behave a bit differently if there is an assumed minimum traversal time, as would be the case for a physical queue, vs. a zero traversal time as would be the case for a logical or information-only queue. I’ll sort that out in a future post, at which I’ll make the same modifications (if and as needed) for the Path and Process components, which maintain internal queue mechanisms of their own. I have thought that processes represented by Process components must always involve a non-zero processing time but I also recognize that some processes only involve making instantaneous decisions. That may call for a new kind of primitive component type.

Another thing I realized as I was reviewing and cleaning things up today was that my original concept of handling discrete event queue items was that they would be created once, with a call to feq.newItem, and then recycled back into the future events queue continuously using the advance function. However, in a lot of cases components will “lose” the future events queue item when they reach a state where they must wait to be activated by an external event. In this case they cannot rely on being able to recycle and existing future events queue item because the handle to it may have been lost. This situation is made even more confusing by the fact that there can be multiple discrete-event timing items active at any one time within a component (i.e., there can be numerous pucks), so keeping track of them might be problematic.

The advance function as it was written (and still survives in the current incarnation of the Arrivals component because it effectively operates independently of any other component). I’m thinking I need to expand the concept of the advance function so it figures out whether to use an existing discrete-event timing item or whether it needs to create a new one. It shouldn’t be too hard to create a handle for the necessary item; the Component code “knows” whether a component is going to be left alone to “die” (i.e., not be recycled through the future events queue and be automatically garbage collected).

The feqCurrent item is always the most recent item pulled from the future events queue. If it’s going to be recycled back into the future events queue we can use the existing advance function. If a new event needs to be created we might implement an “advanceNew” function to create a new item, or we can simply hijack the existing item. I’m going to have to draw out the state values as things proceed so I am perfectly clear on what’s needed. I could simply create new objects for every item I’m going to put into the queue whether it’s recycled or new, but relying on automatic garbage collection to keep up with objects that would be created at such a great rate (this is the most common thing that happens in a discrete-event simulation model, after all) seems extremely wasteful.

It also occurs to me that when defining forward links of paths to downstream components that the process of defining an accompanying upstream link can be automated when the need for it is detected. This would have to be the case when linking to downstream components that are not guaranteed to be able to receive new entities (i.e., they must clear before sending an open signal back upstream to the sending component). This also says that the definition for whether the linking path is exclusive or not is actually defined by the nature of the downstream component being linked to, so the linking path should take on this characteristic automatically, and define the required upstream link, based on whether the linked-to downstream component is exclusive.

It may be that the minimum definitions should be generated by the designer and that upstream links should be defined automatically as part of the post-definition and verification process. A verification process should be implemented to test that all required elements are defined and that the required components and connections are in place to support every defined routing. The direction of paths should be considered as part of this as well.

If that all seems less than clear I feel your pain, but these very insights were the main purpose of today’s explorations. I’m going to work on implementing the cleanup of the linking and exclusivity process tomorrow and the new vs. advance issue in the post after that.

Including thoughts from previous posts and some other items that need to get done, here’s the current to do list. It’s going to keep me plenty busy as you can see. I’m likely to take breaks from this project to work on other things, but since this is something I’ve always wanted to do on my own so I’ll always come back to it. I’m also sure that I’ll continue to add to this list. The main thing is that I’ve gotten the project to a takeoff point where it’s fun to work on and produces highly visible results.

• Standardize linking and exclusivity process
• Resolve and standardize new vs. advance issue
• Rework drawing of Path components so correct elements are always on top
• Rework the Queue mechanism to flexibly handle finite-traversal time and zero-traversal time configurations
• Revisit distribution logic to make sure it’s cycling the way it should be.
• Learn JavaScript’s prototype object pattern and re-implement everything in that in place of the closure pattern I’ve been using; I’ll want to bite that bullet before this thing goes much farther
• Expand Path component representation so it can incorporate multiple line segments
• Add ability to sense reaching tail end of FIFO queue based on stopping to wait on a Path component; collect statistics accordingly (possibly add wait flag to entities so they can test against the next entity in line)
• Look into creating a zero-duration, zero-queue decision component
• Create standardized routing mechanism (to components of different types) based on process logic (vs. distribution logic to multiple components of the same type)
• Implement mechanism to identify combinations of related components into groups (e.g., a group of tollbooths represent a single toll plaza)
• Gather and report system-, component-, and group-level statistics
• Add ability to stream large volumes of output information which can be post-processed and quantified via a parsing mechanism
• Streamline the process of defining the endpoints of Path components (i.e., attach standard nodes to other components and connect to those automatically, which will greatly save on the number of x,y locations the designer must specify manually)
• Add an edit mode that allows designers to change component properties interactively (ultimately including being able to drag them)
• Use the new, completely external mechanism for displaying component data
• Describe how abstract representation can be used to represent detailed layouts and interactions; include ability to flag or alarm situations which would cause conflicts in the real world that would not necessarily be captured in a model unless specifically tested for
• Add the ability to graph outputs as part of reporting
• Add scrolling, animated graphs to illustrate progress as simulations run
• Include ability for users to call up component and entity status by written or graphical display interactively while runs are in progress
• Create streamlined graphical representations of all component types; create data display for Path components
• Add ability to display entities inside relevant non-path components
• Abstract the current x,y locations of all elements and scale them to the screen so the user can zoom in and out
• Add ability for users to interactively change things during runs
• Add Monte Carlo mechanisms to various timing and routing events (beyond what’s already been demonstrated)
• Allow designer to build Monte Carlo and other distributions from acquired data using standardized tools
• Add ability to perform multiple runs and statistically quantify generated outputs
• Make simulation display update at regular intervals of simulated time rather than intervals defined by individual events; also make this “speed” scalable
• Include ability to add arbitrary graphic elements to models (labels, keys, tables, etc.)
• Include ability to display an underlay “below” the model display (e.g., a floor plan of a modeled process)
• Allow user to turn off display and run model in “fire-and-forget” mode where it generates results without wasting time redrawing graphics.
• Allow user to selectively turn different display elements on and off
• Add ability to assign open/close schedules for components and groups
• Add ability to introduce multiple types of entities in model with different processing rules for routing and timing
• Add ability to combine multiple queues into a single, logical unit
• Add ability to adapt stand base components to represent varied and specialized things (this applies mostly to Process components)
• Add ability to save and restore model definitions (in files/XML and in databases, requires PHP/MySql, Node.js or other back end capability)
• Add ability to represent more abstract processes:
• Reintroduce wait..until mechanism that uses the current events queue
• Include pools of resources that are needed by different processes
• Implement non-FIFO queues or collections that receive and forward entities based on arbitrary (user-defined) criteria
• Include ability to accept events that happen according to fixed schedules rather than random ones (e.g., to match observed data)
• Include the ability to change representation of entities and components to represent state changes (by color, shape, labels, flags, etc.)
• Support input and editing of modular packages of information used to define and drive models
• Add ability to represent BPM processes using standard BPMN notation
• Really complex stuff
• Develop more complex, arbitrary node-and-link representation of model, which brings up worlds of complications on its own!
• Polish related sections of code and break them into modules which can be included on a modular basis
• Make modules and examples distributable for use by a wider community
• Write documentation for modules as needed
• Share on GitHub
• Create dedicated project page on my website
• Update and enhance my custom Graph component as well as the simulation framework
• Re-implement this system in a more appropriate language like C++ or at least Java

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!

Today I took a step back to slightly simpler version of the simulation that uses the original version of the Path components (the ones that have the nodes built into them and act like standalone components). I took two steps forward, however, in that I added new complexity to the framework by providing the ability to include multiple entry points and the ability to either step through the simulation or run it so it steps through the simulation automatically. I also added the ability to pause the simulation when it’s running automatically.

Up to now I’ve assumed that components can only be linked together in one line; each component was linked to exactly one subsequent and/or one previous component. I started to allow for more arbitrary constructions when I developed separate nodes that could be linked to multiple incoming or outgoing paths. We aren’t using independent nodes here so we have to recreate that capability using the components we do have. We can start by allowing the Arrivals component to be linked to multiple Entry components. You can see this in the demo; there is one Arrivals component and two Entry components. Each Entry component is linked to a separate Path component and each Path component is then linked to the single Exit component. It’s a pretty simple setup, but it includes everything needed to illustrate the principle.

The code for the Arrivals component includes a few changes. We’ve eliminated the single value for nextComponent and replaced it with an array of values called entryList. This allows the Arrivals component to be linked to as many Entry components as desired.

We’ve also added an additional input parameter to the constructor or initial call, in the form of an entryDistributionArray. This array should have as many primary members as there are time slices in the model (we’ve been going with twelve time slices of thirty time units each). Each member of the array should itself be an array with as many members as there are linked Entry components. This information is used in the forwardEntity method in the following way. The values in the secondary dimension of the array represent the cumulative chance that any given entity arrives at that Entry component, ranging from 0.0 to 1.0 and always increasing. We initialize each array to have values of 0.7 and 1.0, which means that 70 percent of the entities will be forwarded to the first Entry component while the other 30% will be forwarded to the second Entry component. If we had assigned five possible Entry components we might specify a secondary array of [0.4,0.45,0.6,0.9,1.0], which means that Entry components one through five would be expected to receive 40, 5, 15, 30, and 10 percent of the generated entries, respectively. The actual selection is based on the result of a call to Math.random(), which generates a value between 0.0 (inclusive) and 1.0 (not inclusive).

That’s really all there is to it. At this point none of the other components had to be changed. That said, I did add a counter to each Entry component to keep track of the number of arriving entities routed to each. Since I assigned values of 0.7 and 1.0 for each of the 12 time slices we would expect roughly two-thirds of the entities to arrive through the first (left hand) entry components. Since the results are generated randomly and the browser (I tested this only on Firefox and Safari) doesn’t reset the random number seeds when I refresh the page to rerun the model, the exact distribution varies a little bit between runs.

Here’s the code that initializes everything, including the division of arrivals by Entry component.

We’ve assigned the diversion percentages for the arrivals (from the Arrivals component to the various Entry components) by time slice but there may not be a need to add that much complexity. If the division by entry point doesn’t change over time then a single set of values could be used just as easily. I’ve worked with some very complex models that made this assumption.

Tomorrow I’ll continue adding complexity by adding the ability to specify multiple destinations to at least one other component type.

Finally, I will also see if I can’t allow the user to reinitialize and rerun the simulation without having to refresh the whole browser page.

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!

Today I finished putting together a basic Path component. It mostly works like a queue but it has “physical” dimensions that take time for the entities to traverse. It also draws the path, its endpoints, and any entities in their proper positions.

The Path is component three in the demo. It’ll take a lot of clicks to get through it.

(Click on the “Step” button to advance through the model, refresh the page to run it again.)

Here’s the code for the Path component.