R.P. Churchill.com

Today I added the ability for the user to control how the display is updated. Two new buttons have been added to the button row between the 2D display and the 3D display. The second button from the right, labeled “Time” when the page is initialized, indicating that the animations will only be updated on a time interval determined by a new display control timer component. The base multiple is set to 0.5 so the model will process as many discrete-event items during each interval of that length, at which time it will update the appropriate displays. This is done once per screen refresh cycle. This makes the animation much easier to watch, and it also ensure that simulated time advances at a consistent rate. Clicking on that button will change the display to “Ops,” short for Operations, indicating that only one discrete-event item will be processed per screen refresh, and the displays will be updated in the manner we’ve seen up until now.

The rightmost button, labeled “x1” to start, governs the multiplier for the time interval. Clicking on it changes the display to “x2” and multiplies the default time interval for time-based updates by two. The multiplier applies to whatever the base time interval is. If the base interval is set to 0.25 time units then setting the multiplier to two will result in updates occurring every 0.5 time units. The multiplier value does not apply when the display is in “Ops” mode. In theory the multiplier could be set to any positive value above zero (including fractional values) but the demo uses one and two for simplicity.

Last but not least notice that changing the multiplier value takes effect after the next update is completed. This is because the next discrete-event item that triggers the display update has already been inserted into the future events queue using the old multiplier value.

If everything is right to this point then additional components and logic should be able to be added in any way desired. The complexity was increased by quite a lot and only turned up one minor code change. That’s a win in my book. I also compressed the 2D display components a little bit more.

What we have here is a system with three primary process points. Twenty percent of the entities processed are routed over to the secondary queue, which feeds two secondary processes. From there, twenty percent of the entities go to the secondary exit while most go to the primary exit. This might represent a manufacturing system with a primary inspection step. Items failing the inspection get sent to a secondary process to see if the issue can be fixed. If not, the item gets scrapped. If the model was of a simple land border crossing the secondary exit would represent a return to the country of origin. With just a few components we can model a wide variety of processes, but that won’t stop us from adding even more components to give us even more capabilities.

The simulation is taking longer and longer to run with increasing complexity, as we might expect. However, the framework currently redraws the scene after every individual event is processed and can only update sixty times per second. This is great for single-step debugging but a little painful to watch. What we’ll do, then, is change the framework to update the display in uniform increments of modeled time. That speeds things up a lot when a bunch of things are happening in rapid succession but slows things down when not much is happening. I will ultimately give the user complete control over how this update process is handled, including the ability to run the model with no animated display at all. At some point the various animations are only there to confirm that the model is working the way we want it to. The results it generates are entirely independent of the display.

Results? We’ll talk about how to generate those going forward as well.

Today I got a number of things done. I’ll describe them briefly but forego the code listings for today. Too much going on.

I created an external way to graphically represent the non-Path components. These work roughly the same way as the data display objects I’ve been using (and am still using for the Arrivals component, which doesn’t even have to be displayed) but take up much less space and display the entities that are within them. The entities in components are also colored differently depending on whether they have finished their process or traversed their queue. A bare minimum of queue information is provided, and this could probably be eliminated for the simple, one-element process component. This method of display should make things much more visually clear to the user.

The incoming and outgoing nodes are included in the representation of each component. This process will be extended to handle display of the Path components as well, for consistency.

The start and end coordinates of all Path components are now set automatically by referencing the incoming or outgoing node on the non-Path component to which they are attached. The start and end locations still have to be established manually where Path components are attached to each other in series. Still, this saves a lot of hassle for the designer. The code for this was added near then end of the verifyModel function.

This new representation allows more complex systems to be represented in less space. Eventually a lot of the labels and internal information can be squeezed out as well, to allow even more information to be displayed. The amount of information to display or not display should be as flexible and configurable as possible.

The original data display objects are still available. I plan to make them visible by user request to monitor more details than are shown in this newly streamlined version.

I the process of working off some of the TODO: items I have sprinkled through the code I ended up fleshing out the model verification function. It is called after everything is defined but before the model runs. I haven’t let a negative finding prevent the model from running — yet — since I currently have a working configuration. The function also ensures that certain settings are initialized.

Here’s the function itself. Explanations and supplementary listings follow.

The function starts out by verifying that all previous and next component links exists and are valid in a number of ways. Here’s an example of the most general formation. A customized version of the verifyLinks method was created for each component type. Component types that do not support one type of link or another (e.g., Exit components do not include forward connections) do not test those elements. It is possible that these methods can be even more standardized and modularized, and I may look into that at some point.

In general, the method ensures that the count of connections is not zero, that the list of connections does contain references to something, that the references are to objects, that the objects are (likely to be) components by testing for the presences of the componentType property, and that the connections are not to types of components that make no sense (e.g., Entry components cannot be connected to Exit components and vice versa).

The function continues by setting the value of the exclusive property for each Path component based the exclusive property of its terminating non-Path component. This assumes that the exclusive property of each non-Path component has already been set.

Here’s the getNextExclusive function I had to define in the Path component. I noticed that I do this pass-through thing frequently and should come up with a consistent naming convention for methods like this.

The verifyModel function then tests the nextComponentList links of every Entry component to ensure that all connected components are defined to be non-exclusive. Here’s the code for the A customized version of the verifyLinks method was created for each component type. method.

Finally, I moved the mechanism for assigning destination component indices for forward links to here.

Some of the methods return error codes, and these are placed in the scrolling text area. The messages include detailed notes about the components and connections that are incorrectly configured.

I have a comment in place to implement a mechanism to assign the desired distribution method based on the nature of the downstream connections.

I currently have the routing logic attached to the individual components, but there is also a need to ensure that certain combinations of destinations can be reached from the point of view of an entity moving through a system. Moreover, destinations may need to be identitied in an aggregate way, like a toll plaza containing many booths. I will implement a test mechanism to address that process at some point as well.

There are many more things that can be tested or automated in this or similar functions. However, this was a pretty good start.

Last but not least, and not related to this project, I was able to complete another class on Udemy over the weekend, this time about Sass and SCSS.