I’ve mentioned continuous simulation and discrete-event simulation previously but I wanted to take some time to illustrate the differences between them. For today I’m going to keep it simple. The truth is that when you know what you’re doing, you can use either method to accomplish whatever you’d like; the methods can therefore be said to be interchangeable. That said, each method is better at handling certain classes of problems, so let’s talk about what those are.
A major difference between the two, bearing in mind that we’re keeping it simple for now, is how time is handled. In continuous simulation all processing is typically performed in time periods that begin at regular intervals of simulated time. Even if real or simulated events happen between regularly-spaced intervals they are only processed on the specified interval. In discrete-event simulation the events can happen at arbitrary times and each event is processed exactly when it occurs.
Consider the timing diagram above. Let’s imagine that we have two systems that are each initialized and have some processes taking place. Events associated with these processes are shown on their respective timelines in green. As you can see, in the continuous simulation the events occur at regular intervals, while in the discrete-event simulation the events occur at irregular intervals. It is also possible for multiple events to occur at exactly the same time in the discrete-event simulation (shown by the stacked events in green). Events occurring at the same time can be processed in order of arrival or by some sort of priority defined within the system. All events in continuous simulations are processed at the same time, though they may be handled in a specified order within the block of processing done on that interval.
Now let’s consider the arrival of new entities into each system, shown in blue. In the discrete-event simulation these events are processed when they occur. In the continuous simulation these events are likely to be buffered and the processing is likely to be done on the next regularly-scheduled event interval. The same is true of user events, shown in red.
The following comments apply to both kinds of simulations except where noted.
Note that when I mention time in this discussion I am always describing simulated time (except, possibly, for the user events). In a continuous simulation the simulation clock is always advanced by a fixed amount while in a discrete-event simulation the simulation clock is advanced as far as it needs to be to get to the next event. If multiple events in a discrete-event simulation take place at the same simulated time the simulation clock will not be advanced until all those events have been processed. In computer time the event or events can be processed as quickly as possible, the clock can be advanced, and the next event or events can be processed. If simulated time moves more quickly than time moves in the real world (because the simulation is less complex, involves fewer or longer time steps, or has fewer entities than the host computer can process in real-time) then it becomes possible to insert wait states into the simulation so that it runs exactly in sync with real-time. If the simulation is more complex, involves more or shorter time steps, or has more entities than the host computer can process in real-time then there isn’t much that can be done to run the system in real-time.
The time scale of either type of simulation can vary widely. Simulations of subatomic particles might be on nearly infinitesimal time scales while simulations of geologic or astronomic processes might be on exceedingly long time scales. Simulations of human-scale activities like manufacturing processes, building evacuations, and maintenance operations might take place on a smaller range of human scales.
Some simulations take hours or days to run, even on supercomputers. Others might run almost instantaneously.
For most applications simulations will be run without wait states so they proceed as quickly as possible. Simulations for research, analysis, or design are typically run in this way. If the simulation is used for training, control, or games then the desire may be to run it in real-time.
Many simulations are not meant to handle user interactions; they are initialized and run to completion. In my experience these simulatiions are colloquially referred to as “fire and forget.” Simulations for research, analysis, or design are typically run in this way as well. Other types of simulations are meant to respond to interactive user or environmental input, and again these are likely to be for training, control, or gaming applications.
Note that not all systems that run in real time or respond to inputs are simulations. A simulation is intended to be a fairly specific thing, which I will discuss tomorrow.