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.
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.