R.P. Churchill.com

Today I got a lot of updates into the mechanism for forwarding entities from one component to another. The changes were chiefly made to the Queue and Process components with some supplementary changes to the Path component. The first change involved saving the destination chosen when an entity first tries to exit a component. This only applies when using model routing logic. The component then keeps trying to forward the entity to the chosen location until it is successful, at which point it resets the savedDestination property to its initialized value of -1, meaning that the method should generate a new destination.

The next changes involved handling pull requests from downstream components. When an exclusive component forwards an entity it sends a request back to a previous component to forward an entity if one is available. There are several things to consider during this process. One is that the request is only sent if the discharging component goes from being at capacity to being at less than capacity. If a component (usually a Queue in this case) is not at capacity then the upstream component(s) should have been able to forward entities to the present component as needed, so there is no reason to send the pull request. The second consideration is important when there are multiple upstream components that might be pulled from. The code was changed to select the entity that has been waiting the longest. I discussed this in yesterday’s post and I still have to address the method of setting the “age” of each entity.

Finally, I changed the pull mechanism to ensure that the item is forwarded to the component that requested it. It would make no sense to send a pull request and have the upstream component randomly generate a new destination and send the entity someplace else. In order to do this I had to add a new array to the Queue and Process components to store the index of the first non-Path component linked to in each of the nextComponentList references. The array is initialized using the new getNextComponentIDs method, which has to be called when the components are defined and linked but before the model runs. The componentID of the pulling component is relayed to the upstream component, which then cycles through its own downstream connection indices until it finds a match (which it should be guaranteed to do). Once the match is found the upstream component can forward the entity (if it’s available) to the proper downstream component. This method of selecting a forwarding destination overrides the one normally used.

Here’s the new code for the forwardEntity method:

Here’s the new code for the pullFromPrevious method:

Here’s the new code for the getNextComponentIDs method:

The Path component was modified so the pullFromPrevious method could relay the index of the requesting element.

The Path component was also modified to add a method to pass requests for component IDs through multiple paths.

Blissfully I think I’m pretty close to getting the major routing and plumbing issues worked out so I can move on with things that are more “fun” and interesting. That said, the hard part will be done when it’s done. I’ll begin next week by working off the comments and TODOs in the code.

At the end of another week here is the current To Do list:

• Standardize linking and exclusivity process
• Resolve and standardize new vs. advance issue
• Rework drawing of Path components so correct elements are always on top
• New property for forward exclusivity as opposed to receiving exclusivity.
• Formalize and implement method of receiving from multiple upstream components in turn. Implementing and observing this may illuminate the behaviors that will need to be implemented for the general path solution described in one or more previous posts.
• 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
• Add Control, Bag, and Stack components
• Expand function of Process components to handle multiple entities in parallel, in effect making a single component function as if it were multiple, associated ones
• Discrete-event simulation frameworks often include the concept of sets (logical containers that that be iterated and compared for intersection and so on, so that idea should be implemented; this would expand on things were doing now with lists of components and entities; the need for this was inspired by thinking about the bag data structure in general
• Ponder the idea of implementing a combined Queue-Process component
• 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
• Create suite of test configurations to exercise every combination of connections and support regression testing.
• 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

Finally, just for kicks and giggles, I was inspired by a demo I saw at a recent Meetup of the three.js framework for creating 3D models simply. I’m therefore going to add an item to the list to render a simulated system in 3D. I’ll keep it simple, but it should still be pretty punchy. If I go really crazy I’ll run that through a simple VR framework I also saw demoed. I’m sure it won’t be as easy as the speaker made it look, but it’s so much fun it might be a good thing to do over the holidays.

Today I updated the mechanism by which the components pull entities from previous components when there are multiple options. This involves pulling the entity that has been waiting the longest. Each entity is timestamped using a new member named forwardAttemptTime, for which a getter and setter have also been created. In the current implementation the value is set to Infinity when an entity is received and then to the current time when an entity completes its minimum traverse time for Queue components or its process time for Process components. I’m thinking this needs to be updated to the time each entity finishes its traverse or process and then reaches the head of the queue, instead. In this case the timestamp could be stored once with each component rather than once for each entity within each component. That’s how I originally implemented the mechanism. It didn’t work because I updated the timestamp every time a forward was attempted whether it was successful or not. It would have worked correctly if the timestamp is updated correctly. I’ll experiment with that and report back tomorrow. In the meantime the existing animation illustrates the intent.

Here’s the important bit of code. It polls all backwards connections to find the one whose head entity has been waiting the longest. This is why the default value for the timestamp is Infinity and not zero. Once the oldest item is identified the call is sent back to forward the entity to the current component.

Here’s the code that gets the relevant forwardAttemptTime value from Queue and Process components. Per the discussion above this may be reworked.

Here’s the code that defines the example system.

Thinking about this also points out that the pullFromPrevious method needs to call the forwardEntity method from the sending component so it’s guaranteed to forward the requested entity to the right place. If the previous entity has only one forward connection, which is the case in our present example, then there’s no way to make an error. However, if the upstream component is using distributed or model routing logic the situation could become much more complicated. If an upstream component is using distribution logic then it’s safe for the receiving component to request the pull because all of the upstream component’s possible destinations are equally valid. If an upstream component is using model routing logic, however, and the waiting entity is not scheduled to be forwarded to the requesting component, then the pull would not be allowed. Indeed, in this case the upstream component should not even be picked in this case. I’ve added a comment to the code to remind myself of this.

The framework is meant to work without including Path components, which would be the case when transfer between components is effectively instantaneous, as would be the case when simulating an information or logical system rather than a physical system of some kind. We can see here that the system works the same way without them, although none of the queues back up as far because a lot of transit time has been removed from the model.

Visualizations are much more difficult to follow without Path connections and the animated movement of entities. However, once we know that the components and transfer mechanisms work as we expect, we can use them with some confidence.

Here’s the new configuration code.

Today I reworked the future events mechanism to streamline it in a big way. I knew it needed this and the essential insight about how to do it occurred to me in the shower about ten days ago. I decided to do this now because I was going cross-eyed looking at the connection logic, which itself needs one more extension.

The main insight involved the need to recycle the reference to the most recent future event item or to create a new future event item. New items are generated as needed and placed in the future events queue. Items are then pulled off the queue in time order and processed one by one. The items are stored in the feqCurrent variable, which can be updated and recycled back into the queue. The variable should then be set to null, which signals that a new event item will have to be created so it can be placed into the future events queue.

I also created standalone functions to process the reuse or generation of new future event items. The advance function defines and event that takes place by a specified offset from the current time, whenever that is. That’s the most commonly used function and models a fixed delay, process time, or event duration in general. The jump function works the same way except that the absolute time (from time zero, the beginning of the simulation) is used. This function is more likely to be used to specify a schedule of known events as the simulation is initialized.

The code is shown below in its now much abbreviated form.

Here are a couple of examples of the advance function in use. The second example shows the extra parameter being used to reference an entity that needs to be processed within a component.

Today I tried a configuration that included instances of consecutively linked Path components, one exclusive and one non-exclusive. They both worked the way I intended them to once I cleaned up a couple of typos.

Here’s the new code that sets the configuration.

Today I got the new permission logic working. It uses a simpler and more consistent mechanism for determining whether new entities can go into exclusive components and the Path components that feed them. When an entity is ready to be forwarded to the next component it has to check to see if the next component (including the Path components that feed them) is open. It does this by comparing the number of entities in the destination component (and feeding paths) to the maximum capacity of the destination component.

Here’s how the Queue and Process components, each of which can be linked to multiple, incoming Path components, count the number of entities present. Notice that the method also sets the open/closed status for the component, but not the open/closed status for the incoming Path components. This status sets the color of the component when it is drawn. Green and red indicate open and closed, respectively.

Here’s how the Path component does it. Note that this method is recursive to count the entities in multiple Path components linked in series. It has the side-effect of setting the open/closed status for each Path and destination component.

The isOpen calls are made whenever an entity is testing to see whether it can enter a component, when it enters a component, and in some cases when it leaves a component. If an entity entering a Path or destination component and brought the system up to its capacity you can imagine that it might have a problem moving between components in the system. I therefore found it necessary to add a permissionToMove flag in the entity object. This is set to true whenever an entity is received by an exclusive Path component and set to false whenever an entity is received by a non-Path component (that also isn’t an Entry or Exit component).

When an entity leaves a non-Path component it checks to see if leaves the component in an open status (which it should always do). If so, it reaches back to all the incoming paths to set their statuses to open as well. Here’s the forwardEntity code for the Queue and Process components.

Here’s the setPreviousOpen method from the Path component.

It occurs to me that the entire isOpen mechanism doesn’t need to be invoked when an external entity wants to test to see if it can enter. It may be that, since the openStatus of each component should be properly set based on events, we can simplify things by testing against that status directly.