Today, we'll talk about how simulation software works, focussing on event scheduling in DES systems.
Continuous Process simulation is relatively easy. Just loop over all the time steps, updating everything every time step, and so on.
Now, figuring out what order to update everything is a little tricky. Indeed, that's why Extend gives us several choices about how to do that, including crafting our own order.
The default order is "flow order." The idea is to figure out and update any blocks that don't depend on anything from this time step, then the ones that depend on these, and so on, until everything is updated. Imagine connecting all the blocks with arrows, where the arrow points in the direction that data flows: from a block that creates a value to a block that uses the value.
Given those arrows, you first compute a block that doesn't have an arrow pointing to it (any one will do), then delete all the arrows coming from that block. Repeat this until all the blocks are eventually done. If you can't do this, there must be a cycle (arrows in a circle), but that's illegal.
Note that Excel has the same problem, and solves it the same way. Excel also prevents you from building models with circular dependencies.
Implementing Discrete Event simulations is a bit trickier than Continuous Process simulation, because there's no obvious time step. The issue is: what event comes next. For example, if there's an ATM with a customer at it, a teller with a customer, and a generator, there are at least three pending events: which comes next?
Each item has a "lifetime" characterized by a series of events at different times. So, one way to think about scheduling is to think about all the possible "next events," and choose the earliest.
Another way to think about it is in terms of blocks, since an item is always in one block or another. (This is the way Extend does scheduling.) Certain blocks "push" or "pull" items at particular times. Some do both. The movement of an item is always an event. For example:
Recently, we looked at a simulation of a computer processor being time-sliced among different processes (jobs). At the heart of it was a "priority queue": a list of items ordered (sorted) by priority. Priority queues are an important way of scheduling events.
Imagine the following simulation situation:
Which event comes next? It's pretty easy to scan the whole list to find the smallest, but as the list becomes longer, that algorithm becomes increasingly time-consuming.
The obvious thing to do is to keep everything sorted and then scan down the list and insert things where they belong. If you have a lot of items, this can take a long time. (Since it's the heart of the simulation, we want this operation to be fast.) Since it depends linearly on the number of outstanding items, this is called a linear algorithm.
We can do better than linear. By organizing the items in a heap (a specialized tree structure), we can insert new items and remove the earliest one in logarithmic time. Here are a few nice pictures:
Let's try inserting and removing a few values.
Fundamentally, most computers can do only one thing at a time: technically, these are called instructions. Examples of instructions include
Computers execute these instructions blindingly fast, but only one at a time. Thus, it doesn't help to try to do two things at once in a simulation.
However, there are fancy computers with multiple processors, and each processor can compute its own instructions at blinding speed, so now there are two or many more threads of instructions being executed at once.
The trouble with running simulations on a multi-processor computer is that one processor may create an event that is "in the past," as far as another processor is concerned. The simulation software must detect and resolve this anomaly so that the simulation can proceed. All very tricky, but worthwhile if you have a really long simulation to do.