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.
