A Simple Discrete-Event Simulation: Part 17

Today I added an animation to the simulation. There are a lot of things that could be said about this, and I’ll go into just a few of them today. At this point I wanted to get some kind of hack working that would give you something to look at; we can adjust from there. Here it is. You have to click on the step button to get it to step through the simulation. The internal activities are listed in the text area below the animation while most of the same information is being shown on the canvas. When the generated entities are activated for the first time I show them being “spit” into and out of view. The simulation ends at time 360.0, so keep clicking!

By the way, you’ll have to refresh your browser to start over.

So here are a few comments.

I’m trying to interleave an animation mechanism with pseudo real-time features with a simulation where individual steps can be accomplished very, very quickly. This turns out to be a bit of a problem. In previous lives I didn’t encounter this issue.

When I was doing continuous simulations I just did all the calculations for each time step, drew or updated the screen as needed, sometimes with page-flipping to keep it clean, and went about my business. I always made my simulations interactive; the user could always pause (or freeze) at any point, make modifications as desired, and continue on. Alternatively, real-time inputs from users and physical devices in the field changed things, but the system would just react and move on. The time steps in the systems I worked on ranged from a quarter of a second up to forty seconds, depending on the amount of calculation that had to be performed, the size of the simulation being run, and the speed of the computer (and to a lesser degree the speed of the code both as written by the author and compiled by the compiler).

All of the discrete-event simulations I did were fire-and-forget. That is, you started them, let them run to completion, and then you looked at the results. If an animation was generated it was (usually) created from a log file that was written out as the simulation ran. As such there was (generally) no ability to change the simulation while it was running.

The first discrete-event simulation system I wrote was built with SLX (Simulation Language with eXtensibility). It is a C-based language with built-in discrete event capabilities. (It hides all the ugly stuff I have to expose when doing the same things in JavaScript, which is a silly language for such an exercise except that it’s so easy to make live demos for the web!) The SLX code was made to write statements out to a log file that could be read by a companion product called Proof, which has the virtue of being simple, terse, and stupidly fast. (These products have the vice of being somewhat expensive and protected by hardware dongle.)

If you want to do a discrete-event simulation that generates an ongoing display as it runs you have a couple of options. One is that you simply generate or update frames after some number of operations. If you choose a small number of operations you may end up generating frames more quickly than the graphic system can draw them. If you choose a large number of operations you may skip frames or otherwise get out of sync with the graphics system. That might not actually be a problem, but it’s definitely something you want to be aware of and decide to do as a conscious choice. Like Vladimir Nabokov said about his characters being galley slaves, meaning he exercised total control over what they did and what their actions represented while other writers spoke of characters taking on lives of their own in their imaginations, the goal is to understand and be purposeful, always.

That discussion applies whether you are running a simulation (or animation) slower than real time, faster than real time, or in sync with real time. If you want to run in sync with real time, you essentially put wait states into the future events queue that, when pulled off the queue, cause the simulation to wait until the computer’s clock reaches the specified time. In order to make this work, obviously, you have to make sure that the calculations being done in each time span reach completion before the end of the time span.

What I will ultimately end up doing is embedding the movement of the entities (the green circles) into the same discrete-event mechanism that everything else is in.

Last but not least I haven’t shared the whole project for a while, so here it is in all its ugly-but-working glory. The point of these exercises isn’t to show off polished, web-ready production code, but to show the thought processes associated with these projects.

This entry was posted in Simulation and tagged , . Bookmark the permalink.

Leave a Reply