Online Resources

I taught a one-on-one ExtendSim class a few weeks ago.  The student asked about ONLINE resources a new modeler should be aware of.  Great question.  It was an interesting discussion I want to share.

One of the online resources I suggested was the Winter Simulation Conference Proceeding archives. Coincidentally, I noticed that the proceedings from the last conference (2017) has recently been posted.  There are papers on basic simulation concepts that is a must read for everyone!  Even for the advanced modeler, these concepts are a great refresher from time to time.  Here is the short list of suggestions.

Winter Simulation Conference Proceedings (https://informs-sim.org/)

• A Tutorial on How to Select Simulation Input Probability Distributions by Averill Law (2016)
• Inside Discrete-event Simulation Software: How It Works and Why It Matters by Tom Schriber (2017)
• A Tutorial on Simulation Conceptual Modeling by Stewart Robinson (2017)
• A Tutorial on the Operational Validation of Simulation Models by Robert Sargent (2016)
• A Practical Look at Simulation Project Management by Joseph Hugan (2014)
• Information and Process Modeling for Simulation by Gerd Wagner (2014)
• How to Build Valid and Credible Simulation Models by Averill M. Law (2009)

There are also many advanced topics that I think are interesting that you can find information on WSC.  I recently become interested in agent based simulation.  I attended several presentations on this topic this past year at WSC.  After attending these presentations and doing some studying up on the topic, I built an ABS model myself in ExtendSim.  I discovered ExtendSim was a great fit for a certain type of agent based models.  I used some of the advanced database features along with the Queue Equation block and the Query Equation blocks.  If anyone is interested in agent based modeling then I suggest you look up the WSC paper below and look for other good articles on the WSC website.

• Agent-Based Modeling and Simulation by Charles M. Macal and Michael J. North (2015)

I also pointed out to my student there are lots of papers on actual customer models.  We did a search together on the site and found his company had published a few papers on WSC about a decade ago.  What a coincidence.  It turned out to be a great resource for him. 

Here are other great online resources.

• ExtendSim Exchange (https://www.extendsim.com/forums/)
• ExtendSim Youtube Channel (https://www.youtube.com/user/ExtendSim/featured)
• LinkedIn ExtendSim Group (https://www.linkedin.com/groups/1705447)
• Blogspot (http://simulationsoftware.blogspot.com/
• ExtendSim Industries Page (https://www.extendsim.com/solutions/industries)

You might be reading this post on either Linked In or the Blogspot - so you might know about one and not the other - so I posted both.  And if you have other online resources that I have not mentioned then please share by adding it to the comments!

To Animate or not to Animate

Animation is an important feature of a simulation model. And it’s a great way to introduce a model to someone who has never seen a simulation before. Well-thought-out model animation can grab someone’s attention like nothing else and can help that person see how a system works. I have found that many new modelers believe the primary purpose of animation is to serve as eye candy once the model has been developed. However, animation should play a much bigger role than just being a selling point of the model.  

Animation should be a critical component throughout the model-building process, in both debugging and validation. My philosophy is that if you want to monitor something, then animate it! If it is an important result, then animate it! If something is not animated, then there is a good chance you will IGNORE it for most simulation runs! So let’s discuss some ways animation can be used to our advantage in these situations.

Item animation is very useful in debugging the routing of items. For example, if we have a system where only red items should be traveling through the first path and only blue items should be traveling through the second path, item animation can show that, indeed, the red and blue are going through the right paths.

The alternative is to constantly check out History blocks strategically placed throughout the model. History blocks are great, but you must open the History block up and inspect the results for it to be useful! How often is this actually done? I inspect the History blocks often but not all of them on every run.

Also notice the animation of the numbers on the Queue and Activity blocks above. This shows the actual number of items in each block. It is useful for finding bottlenecks in the system, but often, these numbers are hidden inside h-blocks. However, there is a way we can still monitor important statistics when the blocks are inside h-blocks.   

Below is a good example of h-block animation for the purposes of debugging. This is the Emergency Department model from the ExtendSim \ Examples \ Discrete Event folder.  Check this model out sometime to see how it has been constructed.  Notice the results that are posted on top of the h-blocks. This animation would be impossible to overlook.  

The resulting patients-per-day amount is clearly animated (shown by the red arrow) when we run the model.  Let’s say we made a change to the logic of how we segregated the Main ED patients (labeled as ED Room) and the Fast Track patients (labeled as FT Room). If there were a problem with our new logic, then that would be OBVIOUS from the animation. If we didn’t animate it, then we might not notice the bug until much later. With my luck, I wouldn’t notice it until I had forgotten about the change to the logic, and at that point, the time to debug would be significant!  Animation can help bring bugs to our attention faster.

Now let’s talk about the high-level animation that we want to be eye-catching. Just because we build the model with the animation shown above does not mean that we can’t also put a nicely animated graphic on top. I have another version of the model shown above in which I have encapsulated the flow chart in another h-block and have animated the h-block. The model shown below is the result.

From the customer’s point of view, this type of animation is often necessary for them to visualize the system.  Not everyone can visualize how a system is working by simply watching the numbers like in the first two illustrations.  So, this must be addressed unless the model is built solely for your own consumption.

Finally, when should you think about how to animate the model? That is an important question! If I had a nickel for every time I heard someone say, “Please forgive me for the messy model. I will clean it up and add the animation later when it is finished…” Arrgh! This is a bad strategy. The most valuable benefit of animation has totally been missed.  You should use the strategies mentioned above to help you debug your model as you are building it.

Because animation is so important, you should think through your animation strategy at the beginning of the model-building process. Make it intentional and not an afterthought. Add animation to help you debug as well as the top-level animation that is eye-catching. And most importantly, don’t put off the model clean-up and animation until the end of the model; do it as you are building the model so you can take advantage of the benefits yourself.

Improving Performance in Resource-Constrained Systems

I worked on a simulation study last year with Dr. Holt (University of Washington) and Dr. Srinivasan (University of Tennessee). The results of the study surprised me. It made me start thinking differently about variation and its effect on systems. It might change the way you look at bottlenecks in a resource-constrained system as well.

We modeled a multi-project system, but the results we found can be applied to any system. This multi-project system (think of the projects as engineering projects) required various resources at different stages. We modeled a variety of project structures. The projects we modeled used several common resources. The primary output we studied was the project flow time, or the time it takes a project to complete the system.

It is very difficult to correctly determine the appropriate workload that should be placed upon resources in this environment. There is no question that putting too little work into the system will tend to starve key resources. And while there is pressure to keep resources busy, overloading them usually results in unfavorable outcomes like projects taking too long.

In an ideal setting, work schedules can be developed in advance, so that resources have just the right amount of work allocated to them at various points in time. However, in the project world, demand is highly uncertain, workflow is quite unpredictable, and task durations have significant variability. Even the best-planned schedules become difficult to execute in this environment. And when many different resources are used multiple times in a single project and frequently shared between projects, any unexpected delay in a single task can cause significant ripple effects delaying one or more projects. Even a small delay in a task far away from a key resource can cause chaos in the complicated and interrelated schedules that exist in a project environment, and attempts to tightly schedule projects are soon abandoned.

Our study outlined several steps to dramatically improve the performance of these organizations and I want to talk about two of them here. 1. Determine how resources should be loaded 2. Identify the appropriate level of reserve resources

The first step is not a new concept. This is basically controlling the amount of work in the system, and there are several approaches to implement this. In manufacturing, you might refer to it as CONWIP or Constant Work in Process. In the project-management environment, the term is CONPIP or Constant Projects in Process. We applied a slightly different mechanism, but it had a similar effect as CONWIP or CONPIP. In our system, we monitored the backlog of work for the resources. This backlog would generally not be completely present in the immediate queue of work at that resource. We would only release new work into the system once the bottleneck resource was below a specified threshold.

The chart below shows the first set of results from the resource loading study. The X-Axis shows the resource workload. For example, at 100 percent, the bottleneck resource has enough work in the system to keep it busy for 36 days. At 200 percent, the bottleneck resource has enough work in the system to keep it busy for 72 days. The blue line shows the effect that an increased workload has on the average flow time. As more work is pushed into the system, the average flow time increases. Increased flow time means it takes longer for projects to complete, so customers are much less happy! Longer flow times can be detrimental to a company. The black line is plotting the throughput. With an increased workload in the system, more projects can be completed, but at a certain point, the increase is negligible.

The red line is something we called the project value index. This is defined as the number of projects completed over a given period divided by the 90-percent probable flow time. The project value index is a value we want to maximize (more projects completed while decreasing flow time). We tend to want to be just a bit to the right of the high point on the project value index. This is a good balance of throughput.



The next issue we studied was the use of additional resources. The results of this study are what really surprised me. The typical thought process for improving a system is to add resources to the bottleneck. Then to keep improving the system, you would find the next bottleneck to add resources to. This feels like the natural progression for improving projects, right? In the system studied, we did have a clear bottleneck. We had nine resources. When the bottleneck resource was at 100 percent utilization, the other resources ranged from 50 percent to 75 percent.

Another strategy we tried was to use an Expert resource. This is a resource that can be used to help any other resource, not just the bottleneck. This would be the most experienced staff member that can do everything. We didn’t want this expert resource working just at the bottleneck resource. The task durations were all random. We let the expert resource help any resource when the task was taking longer than the expected value. These expert resources would ONLY be requested for help after the task duration had exceeded the expected mean value. For example, let’s say the expected task duration was six days. If the task was not complete by day six, then the expert resource would be requested to help complete the task to “shorten the long tail” of the task duration. The expert resource is specifically used to reduce the long tail on the right side of the service time distribution.

In the chart below, we used the Project Value Index to compare the two strategies of a) adding an Expert resource, which helps reduce the long task times and b) adding a resource at the bottleneck. As you can see, using the Expert resource had a significantly better impact! Wow. I did not expect this.



 Here is what I learned from this study: When a task consumes a resource for an excessive amount of time, it not only delays this project from completing but it also delays every project in the queue for this resource. So long-tail tasks have an impact on potentially all the projects in the system, not just on the individual project. Focusing on these long-tail tasks, even on non-bottleneck processes, has a bigger impact on the system than just focusing on improving the bottleneck process.

That is something you should noodle on. This concept can of course be applied not only to project-management systems but also to many other resource-constrained systems.