Skip Navigation

2.3: Simulation Paradigms

Difficulty Level: At Grade Created by: CK-12
Turn In

Lesson Objectives

  • Explain the difference between Live, Virtual, and Constructive (LVC) simulations.
  • Explain the two main categories of computer simulation based on how time is represented.
  • Describe the basic structure of a discrete-event simulation.
  • Gain a basic understanding of the mathematical operation of integration and three methods used to approximate integrals.
  • Explain the basic concepts of agent-based simulations and learn how to develop one using a simulation language.
  • Describe the basic concepts of system dynamics simulations.


A persistent software entity that carries out tasks on behalf of a user or another program with some degree of independence or autonomy.
equivalent model
A mechanical device or electrical circuit that represents the mathematical behavior for the system of interest.
event list
A list containing the next time that each event will occur.
event type
An event is described by a type, which indicates the code that will be used to process that event. For example, an event that indicates a car ignition started would be processed differently than an event that indicates a car has arrived at a specific destination. This is usually handled in a simulation by calling a function associated with the event type, which has the necessary logic to process the event and schedule new events.
A mathematical operation that calculates the continuous sum of a function over time.
numerical approximation
A computer algorithm used to find an estimate of the value of an integral.
random number generator
A computational or physical device designed to generate a sequence of numbers or symbols that lack any pattern, i.e. appear random. Random number generators have applications in gambling, statistical sampling, computer simulation, cryptography, completely randomized design, and other areas where producing an unpredictable result is desirable.
scale model
A physical model of a system that might be larger, smaller, or the same size as the system it represents.
simulation clock
A variable giving the current value of simulated time.
steady state
If a system is in steady state, then the recently observed behavior of the system will continue into the future. In many systems, steady state is not achieved until some time has elapsed after the system is started or initiated. This initial situation is often identified as a transient state, start-up or warm-up period.
A collection of entities (e.g., people or machines) that act or interact together toward the accomplishment of some logical end.
system state
The collection of state variables necessary to define what is happening in a system at a given point in time.

Check Your Understanding

  • What does it mean for simulations to be characterized by how people interact with them?
  • Is there only one way to represent system behavior in a simulation?
  • What does it mean to model time as discrete instants and continuous flow?
  • Which simulation paradigm requires about two years of college-level calculus and differential equations to represent the models?
  • Which simulation paradigm represents a discrete individual or organization with a set of characteristics and a reasoning system that governs its behaviors, decision-making, and interactions?
  • Which simulation paradigm includes representations of feedback loops and time delays that affect the behavior of the entire system?


A computer simulation is software that models the behavior of some real or imagined system over time. Systems modeled in simulations can include physical systems (e.g., cars, planes, wind turbines, manufacturing equipment, etc.) or living systems (e.g., animals, people, ecosystems, etc.). It is often the case that people need to interact with simulations for some purpose. For example, people interact with video games by controlling an avatar in the virtual game world. The first section in this lesson is a discussion of how simulations are categorized based on how people interact with them.

The remainder of this lesson is focused on defining several commonly used simulation paradigms. As defined in the previous lesson, a paradigm is an approach for developing a simulation program. A paradigm specifies the concepts used to construct simulation models, what relationships may exist among those concepts, how the concepts may be organized and viewed by the modeler, and the rules governing the construction of simulation models. Common simulation paradigms used today include discrete-event simulation, continuous system simulation, agent-based simulation, and system dynamics.

In its simplest form, a simulation must model two things: time and behavior. There are two common ways in which time is represented in simulations: discrete-event and continuous. In discrete-event simulation, time jumps from event to event in discrete steps, and there is a sudden change in at least one of the system state variables. In continuous simulation, models are defined by differential equations that allow both the state and the simulation time to change smoothly and continuously. The way discrete-event and continuous simulations model time forms the basis for all other simulation paradigms.

Behavior in a simulation needs to capture how the system being modeled will change in the future, given its present state. If we consider a car’s driver as a system, then modeling the driver’s behavior might mean representing how the driver decides where it should go, by which route, and how fast to travel. Once the driver arrives at his destination, the model should contain behavior for the driver to make the next decision (destination, route, speed). In addition to the discrete-event and continuous paradigms, agent-based simulation and system dynamics are commonly used approaches for modeling behavior. Agent-based simulation is used to represent the actions and interactions of autonomous agents (e.g., individuals or organizations) with a focus on assessing the effect that the agents’ behavior might have on the system as a whole (e.g., how do individual drivers’ behavior affect traffic). System dynamics is an approach to understanding the behavior of complex systems over time. It deals with feedback loops (when information about the past influences the system’s behavior in the future) and time delays that affect the behavior of the entire system (e.g., cause-and-effect relationships of traffic congestion and air pollution).

Agent-based simulation and system dynamics are paradigms more focused on how to model behavior, which means that they are not bound to a specific approach for managing time. In other words, they can use either discrete-event or continuous time approaches. While it is more common for simulations to use one specific approach to managing time (discrete or continuous), it is possible to have a simulation that uses both approaches together. This is not trivial to implement, but there are some problems that are best modeled by mixing time. The way people interact with simulation and each of the simulation paradigms will be described in more detail in the following sections.

Live Virtual and Constructive Simulations

We can characterize M&S by the way in which people interact with them. “Live” simulations are those in which real people operate real systems for a fictitious reason. An example of this would be fire fighters using their real equipment against a real fire but under controlled conditions, to practice fire response. “Virtual” simulations are those that involve real people operating simulated systems. An example of this would be a flight simulator or driving simulator where you are acting as the pilot or driver, but the vehicle itself and all of its interactions with the pilot or driver are simulated. In this case, the simulation represents an approximation to the physics of the vehicle, but the human represents the uncertainty of how a real operator will interact with the vehicle. The last category is “constructive” simulation, which involves simulated people (or no people) operating simulated systems. An example of this would be a Computer Aided Design (CAD) model or a military campaign simulation. This type of military simulation was made famous by the movie WarGames, in which the supercomputer WOPR made decisions by itself about thermonuclear war. In both these examples, humans are not needed to actually operate the model or simulation, as all the information and intelligence is contained within the simulation.

Live simulations are not computational, in that there is no computer-based simulation representing an aspect of the real world. They are role-playing based and may use a combination of people and real systems. Virtual and constructive simulations include computational aspects, in that a computer-based simulation represents some or all of the real world system. It is possible to link simulations within one of these domains, for example networked video games are an example of virtual-virtual simulation interaction. It is also possible to link simulations across these domains. For example, live-virtual simulation interaction might include a virtual human-in-the-loop flight simulator being linked with live pilots flying real airplanes for the purpose of a training exercise. These types of links can occur, but there is a complex set of issues that must be resolved to enable the interaction. These types of problems commonly go by the name Live Virtual Constructive (LVC) or LVC Interoperability.

Discrete Event Simulation

In discrete-event simulation, the operation of a system is represented as a sequence of events. Each event occurs at an instant in time and represents a possible change of state in the system. A discrete-event simulation is characterized by its system state variables, which is a collection of all information needed to define what is happening in the system at a given point in time. To illustrate the idea of states, events, and state variables, consider simulating a car. A car might be represented by the states “car off,” “car on/stopped,” and “car moving,” as shown in Figure below.

Simple Car Model.

Receiving the event

start ignition

would change the state from “car off” to “car on/stopped,” and receiving the event

press accelerator

would change the state from “car on/stopped” to “car moving.” While in the state “car moving,” an event called


could be used to schedule the car to arrive at a specific destination at a specific time. The arrow in Figure above circles back into the “car moving” state since the car will remain in motion during its travel the destination. If no


events are scheduled, the state of the car would remain as “car moving” until a new event

brakes engaged

changed the state to “car on/stopped.” The car would transition to the state “car off” only when the event

stop ignition

is received. In this example, the system state variables include information about the ignition, accelerator, and brakes.

In addition to the system state variables and the logic of what happens when system events occur, other common components of a discrete event simulation include clocks, event lists, random number generators, statistics, and ending conditions. There are many good references and resources on discrete-event simulation; an Internet search will turn up papers and slides from many college classes. The description of these components, given below, is adapted from a description found on Wikipedia.


The simulation must keep track of the current simulation time, in whatever units are suitable for the system being modeled. Each event is assigned a time stamp, which indicates when in simulation time the event will occur. In discrete-event simulations, time “hops” because events are instantaneous – the simulation clock skips to the next event time stamp as the simulation proceeds.

In the car example above, consider the events

start ignition, press accelerator


engage brakes,

each of which occurs at distinct points in time. If we assume they occur at times 1, 10, and 12, respectively, then simulation time jumps from 1 to 10 to 12 as these events are processed. In discrete-event simulation, there is no concept of time flow between these discrete instants.

Event List

The simulation maintains at least one list of simulation events. An event is described at least two attributes: the time at which it occurs (i.e., time stamp) and a type (e.g.,

start ignition, press accelerator


engage brakes

). This is sometimes called the “pending event set” because it contains events that have been scheduled but not yet processed. Time stamps are commonly represented as an integer value, but some simulation frameworks also allow the time of an event to be specified as an interval (i.e., the start time and end time of the event). The pending event set is typically organized as a priority queue, sorted by event time (or time stamp). Regardless of the order in which events are added to the event set, they are removed in strictly time stamp order. The flow of simulation time in a discrete-event simulation is therefore controlled by the event list.

Using the car example, consider a simulation that represents 3 cars: Mini Van, Convertible and Sedan. The event list for the simulation would contain events for each car being simulated and the times those events are scheduled to occur. An event has structure, meaning it will have defined fields that represent the information to be processed. The

start ignition, press accelerator


engage brakes

events have the following fields:

Event type, Car id, Timestamp,


the arrival event has fields:

Event type, Car id, Location 1, Timestamp, Location 2, Timestamp.

Since each car starts at different times, each will have a different timestamp for their

start ignition

event. The event list might contain the following entries

“start ignition, mini van, 1”, “start ignition, convertible, 5”, “start ignition, sedan, 11”.

As the simulation runs, more events will be generated and included in the event list. For example,

“press accelerator, convertible, 10”

would be inserted into the event list after

“start ignition, convertible, 5”

but before

“start ignition, sedan, 11”.

The event list representing this set of events is shown in Figure below.

Event List (a) with start ignition events and (b) adding press accelerator event.

Random-Number Generators

Simulations frequently use random number generators to create input data that approximates the random nature of real-world events, for example the arrival of traffic at an intersection. Computer-generated random numbers are usually not random in the strictest sense, as they are calculated using the probability density function. Probability density function is a function that describes the relative likelihood for a random number to take on a given value.

One problem with the random number distributions used in discrete-event simulation is that the distribution of event times may not be known at the start of the simulation. In other words, what should be the time stamp for all of the

start ignition

events when they are first scheduled? Because we don’t know what the time stamps should be, the initial set of events placed into the pending event list will not have timestamps representative of the steady-state distribution. Steady state is property of a system where recently observed behavior of the system continues into the future.

Consider the car simulation, events generated at the beginning of the simulation will eventually cause new events to be scheduled (e.g.,

start ignition


press accelerator

to be scheduled). If all of the

start ignition

events are scheduled with the same time stamp, that would not represent steady state because in the real world, how realistic is it that everyone starts their car at exactly the same time? And if all the

start ignition

events are scheduled with the same time stamp, then all the

press accelerator

events will also have the same time, and so on.

This is where random number generators come in; they allow the simulation developer to mimic real life randomness to the time events in the simulation. For example

start ignition

event could be the time when a driver turn on his/her car in the morning to go to work. Let’s say the driver, on average, starts ignition at 8:00 am, but does not leave before 7:30 am nor after 8:30 am. A random number generator is used in the simulation to pick a time when the traveler turns on his/her ignition, based on an average person’s habits in the morning. This process is repeated for everyone that is being represented in the simulation, with a different random number generated for each person. Due to the random numbers associated with the time stamp of events, eventually steady state will be achieved after some time has passed. This is called “bootstrapping” the simulation model. In gathering statistics from the running model, it is important to either disregard events that occur before the steady state is reached or to run the simulation for long enough that the bootstrapping behavior is overwhelmed by steady-state behavior.


The simulation typically keeps track of statistics on different properties of the system. In the car example, this might include statistics on the number of cars entering a roadway during a specific time period (e.g., rush hour traffic), or the average travel time for a car to get from point A to point B. To keep these statistics, you will need to save important information into a data file (also referred to as log files or data logs) so you can analyze the data. So, if you were interested in keeping statistics on travel time, you would need to log each


event and compute statistics on the average time a specific car (or maybe all cars) took to travel between two locations.

Ending Condition

Because events are bootstrapped, theoretically a discrete-event simulation could run forever. Therefore, the simulation designer must decide when the simulation will end. Typical choices are “at time \begin{align*}t\end{align*}t“ or “after processing \begin{align*}n\end{align*}n number of events” or, more generally, “when statistical measure \begin{align*}X\end{align*}X reaches the value \begin{align*}Y\end{align*}Y.” In the car example, the ending condition might be “after 1000 cars enter the roadway,” “after 6 hours of simulated time,” or “when the average travel time reaches 30 minutes."

Main Loop of a Discrete-Event Simulation

A commonly used main loop of a discrete-event simulation is shown in Figure below. This would be the main body of the simulation. The section called “Start” is the initialization phase, where all of the state variables, clock, and ending condition are set. Also during initialization, an event is put into the event list to get the simulation started. For the car simulation where three cars are being modeled, you would schedule

start ignition

events for each car. This is when the use of random number generators is needed to assign time stamps.

Discrete-Event Simulation Engine Logic.

Once initialization is complete, the simulation will spend the majority of its time in the “Do or While Loop.” This part of the simulation will continue to run as long as the ending condition has not been met. During this time, events are pulled from the event list (smallest time stamp first) and processed, new events are scheduled and put into the event list, and the clock is advanced to the time stamp of the event processed. Events are logged into data files and statistics computed on the measures of performance of the simulation.

Once the ending condition has been met, the simulation will execute the logic to end the simulation. In the car example, the

engage brakes


stop ignition

events would be scheduled for each car so that the simulation exits gracefully and a statistics report on all measures of performance can be generated.

Continuous Simulation

In M&S terminology, continuous simulation is sometimes referred to as dynamic simulation. A continuous simulation attempts to recreate the behavior of a physical system through time. A continuous simulation is typically defined mathematically using differential equations. It takes about two years of college-level calculus and differential equations to completely understand the mathematics behind most models. But, here is the good news: sophisticated simulations for well-behaved problems do not require this much rigor. They can be built using standard techniques, a model expressed as a block diagram, and a basic understanding of integration.

Let’s start with integration. Suppose you have a swimming pool that needs to be filled. One way to fill the pool is bucketful by bucketful. The result of adding one 10-liter bucket of water every minute is shown in Figure below. Each bucketful is represented by a blue line in the graph on the left. The blue lines extend up to 10 because the bucket size in this example is 10 liters. The green stair-step line on the right is the total amount of water in the pool versus time. The total amount of water in the pool equals the volume in the first bucket plus the volume in the second bucket plus the volume in the third bucket and so on.

Add a 10-liter bucket of water every minute.

Mathematically this sum can be written as,

\begin{align*}v_N = b_1 + b_2 + b_3 + \ldots + b_N\end{align*}vN=b1+b2+b3++bN

where, \begin{align*}b_1\end{align*}b1 is the volume in the first bucket, \begin{align*}b_2\end{align*}b2 is the volume in the second bucket, and so on for a total number of \begin{align*}N\end{align*}N buckets. The total, \begin{align*}v_N\end{align*}vN, is the volume of water in the pool after \begin{align*}N\end{align*}N buckets. The same sum can be written using so-called summation notation as,

\begin{align*}v_N = \sum_{n=1}^{N} b_n\end{align*}vN=n=1Nbn

If this is the first time you have seen this notation, don’t worry it is easy to decode. The \begin{align*}n=1\end{align*}n=1 at the bottom of the summation symbol represents the first number in the sequence. The \begin{align*}N\end{align*}N value at the top of the summation symbol is the last number in the sequence. In this case the complete sequence for \begin{align*}n\end{align*}n is 1, 2, 3, and so on up to and including \begin{align*}N\end{align*}N. The summation symbol itself tells us to take each value in the sequence \begin{align*}b_1, b_2, b_3\end{align*}b1,b2,b3 and so on up to \begin{align*}b_N\end{align*}bN and add them together.

Now, suppose we have a 2 liter cup instead of a bucket. Our faucet fills this cup fast enough that we can dump one cupful into the pool every 12 seconds. The graph of adding water by the cupful is shown in Figure below. Notice the stair-step height in this figure is smaller than before, but there are a lot more steps. After 5 minutes, the total amount of water in the pool is the same in both cases. Except for the fact there are more cups of water to sum up the equation for this situation looks very similar,

\begin{align*}v_M = \sum_{m=1}^{M} c_m = c_1 + c_2 + c_3 + \ldots + c_M\end{align*}vM=m=1Mcm=c1+c2+c3++cM

Add a 2l cupful of water every 12 seconds.

Finally, suppose you simply attach a hose to the faucet and let the water flow directly into the pool. The graph of this situation is shown in Figure below. With a smooth and continuous flow, \begin{align*}f\end{align*}f, into the pool, there is no stair-step shape in the total volume plot and the left plot for water added has changed to a flow rate in liters per minute. In this simple case where the flow rate is constant, the total volume of water in the pool versus time is described by a sloped line and the slope of the line is equal to the flow rate.

The total volume of water at any moment in time is still a sum; however, it is now a smooth, continuous sum called an integral. The total volume of water added to the pool is the same as the area under the blue line in the left-hand graph in Figure below between any two times. The mathematical equation looks like this,

\begin{align*}V(t) = \int^{t}_{0} f(\tau) d\tau\end{align*}V(t)=t0f(τ)dτ

The mathematical symbol for integration looks like an elongated “\begin{align*}s\end{align*}s” to remind us of a sum. The notation means that the volume of water in the pool at time \begin{align*}t, v(t),\end{align*}t,v(t), is equal to the smooth, continuous sum (i.e., the integral) of the water flowing into the pool between a starting time of 0 and an ending time of \begin{align*}t\end{align*}t. Here the flow rate, \begin{align*}f(\tau)\end{align*}f(τ) is constant with respect to time but that is not necessarily a requirement. For arbitrary functions of flow versus time the integral is difficult to solve explicitly but we can solve it using a simulation. For a constant flow the integral is easy to solve.

Use a hose to fill the pool.

So here is a quick summary. Integrals are important because we use them to write the mathematical models that describe the various relationships in our problem. We then use a simulation to evaluate the integrals. Discrete-time simulation solves them using stair-step approximations and summation while continuous-time simulation uses numerical techniques for integration (often referred to as “numerical methods”). For special cases of \begin{align*}f\end{align*}f (pool filling example above), we can simply write a closed-form equation. For example, the closed-form equation for the integration of a constant flow is easy. For our pool-filling problem, the closed-form equation for total volume is the flow rate times the total time or,

\begin{align*}V(t) = \int^{t_{stop}}_{t_{start}} f(\tau) d\tau = f \times (t_{stop} - t_{start})\end{align*}V(t)=tstoptstartf(τ)dτ=f×(tstoptstart)

When the flow is not constant, the integral is more difficult to solve. Piecewise constant flow rates, that is, constant at one rate for a while then constant at another rate for a while, can be solved by finding the contribution due to each piecewise constant period. If the flow varies continuously with time, the normal situation, college courses in calculus and differential equations come in handy for finding explicit solutions.

Discrete M&S attacks the integration problem by breaking the problem into small steps and assuming the flow is constant during each step. Continuous M&S uses various methods that approximate the value of the continuous integral. For slowly changing inputs, either method works reasonably well. For rapidly changing inputs, the small-step approach tends to run slowly because of the sheer number of steps needed. Continuous M&S addresses this problem using an approximation to the integral. Indeed, approximating integrals is really what continuous M&S is all about.

In general, there are three ways to approximate the continuous integral: scale models, equivalent models, and numerical approximations. Scale models are still in common use to simulate the behavior of ships and aircraft in water tanks and wind tunnels. A scale model is a physical model that is built to be smaller, larger, or the same size as the real-world system being modeled. The model’s geometry, mass, inertias, and other physical properties are scaled up or down so that the model exhibits representative behavior in a scaled environment. Scale models are still commonly used when the behavior of air or water flow needs to be examined. In most other areas, however, numerical approximations have eliminated the use of scale models. Equivalent models are created by mapping the model’s equations into a mechanical device using springs and masses or an electronic circuit that consist of resistors, amplifiers, capacitors, and inductors2. Multiplication by a constant employs an amplifier. Energy loss can be achieved using a resistor. Mathematical integration is accomplished using a capacitor. Different arrangements of these components can model relatively complicated systems. Equivalent models had their heyday in the 50s and 60s but have been almost entirely replaced by numerical approximations on digital computers. Numerical approximations form the basis for all computer-based continuous simulations.

Numerical approximation methods try to estimate both a function’s value and its slope. The slope is then used to produce a better estimate of the function’s behavior between two points. If we know this behavior, we can produce a better estimate of the integral. Techniques are more or less sophisticated depending on how they estimate the slope. Discrete simulations, for example, always assume the slope is zero. This is a zero-order method that gives rise to a telltale stair-step representation. The least sophisticated continuous simulation technique, yet still acceptable in many applications, is Euler’s method. Euler’s method is a first-order method because it evaluates a slope at only one point. This point and its slope are then used to find the next point and the process continues. Integration is no longer a sum of stair-step values but rather, consists of a sum of trapezoids. Higher-order methods probe the slope at several and thus obtain a better estimate of the average slope. These methods are called Runge-Kutta methods of various orders. Euler’s and Runge-Kutta methods are relatively general and can be used to solve a wide variety of continuous models. In special circumstances, application-specific numerical methods have been developed that are more efficient than Runge-Kutta methods. These methods are not general, since they work well only for the class of problem that led to their development.

Agent-Based Simulation

One approach that can be used to explore the behaviors and interactions of individuals or organizations in particular situations or environments is agent-based modeling and simulation (ABMS). The individuals modeled could be many things, such as humans, animals, bacteria, blood cells or molecules. The organizations could be any group of individuals whose behavior could be characterized as the behavior of a group. Examples might be political organizations, terrorist organizations, legislatures, military organizations, or towns.

What are ABMS agents like?

Each agent in an agent-based model represents a discrete individual or organization with a set of characteristics and a reasoning system that governs its behaviors, decision-making, and interactions with other agents in the model. The agents exist in an environment defined by the model. The agents interact according to a set of protocols defined in the simulation to represent how the individuals might interact in the real world. Each agent can recognize and reason about the traits of other agents that it comes into contact with in the simulation. The agents are autonomous, that is they have their own reasoning and decision-making approaches. Each agent has a memory, or history of past state, and learns and adapts from experience. It changes its behaviors in response to new knowledge, experiences and communications.

An ABMS can consist of a set of homogeneous agents, e.g. agents that represent individual people and have the same characteristics and behaviors, but in many complex systems there are a set of heterogeneous rather than or in addition to homogeneous agents. They may have different attributes, different reasoning approaches, and different behaviors from one another.

Building Agent-based Simulations

In designing an ABMS the following questions should be asked and answered:

  • What are the questions that the model is trying to answer?
  • How will the model be used?
  • What kinds of inputs are available (either real or synthetic data) to drive the model?
  • What real-world characteristics or behaviors will the agents need to represent in the simulated world?
  • What kinds of interactions and behaviors do we want to explore?
  • What are the characteristics or attributes of each agent (or class of agents)?
  • What types of outputs will be useful in answering the questions needed by the user?
  • What kind of model development tool or framework supports the needs of this model?
  • How will you develop and represent the agent’s states, knowledge and behaviors?
  • All models are a simplification of reality, so which aspects of the system will be represented with more detail or fidelity?

When to use ABMS approaches

An agent-based modeling and simulation approach should be chosen when the domain can naturally be represented by a set of agents and their interactions and behaviors in a particular situation or environment. The agents should have discrete behaviors and decisions and the model should require dynamic, adaptive behaviors of the agents. ABMS approaches are useful when the agents have dynamic relationships with other agents, that is, relationships that form and dissolve in response to the agents' experiences.

An example of a framework that can be used to experiment with agent-based modeling and simulation is NetLogo3 developed at Northwestern University. NetLogo is good for rapid prototyping and uses the easy-to-learn LOGO language. It provides a Graphical User Interface (GUI) designer and a visual representation of the world using slider bars, buttons and graphs. Individual agents in NetLogo are referred to as “turtles.” Agents may have a “breed” that allows separation of turtles by any desired classification. Each turtle has a memory, and for each “tick” of time, all turtles are “asked” to execute their desired procedures.

Simple Example: “Germs on the Playground”

The NetLogo User Manual provides easily accessible and thorough instructions including tutorials and a Programming Guide. The NetLogo download includes a model library which can be explored to see how models are built. We encourage the learner to do much experimentation with these resources.

To help novice modelers begin exploration of NetLogo, we include a walk-through illustration of the building of a very simple model using NetLogo. The NetLogo User Manual should be consulted for more extensive explanations and examples.

Germs on a Playground

The example model presented here, “Germs on the Playground,” represents a set of children playing on the playground for a recess period. At the beginning of the recess period there is an initial set of children who are infected with germs. As they come within a radius of one step (an arbitrary size of an agent’s step) of an uninfected child, they transmit germs to those uninfected children. The scenario here is that these hypothetical germs are transferred from one agent to another by touching or are airborne if the agents are sufficiently close to each other. Please note that this model is not medically correct, but is meant to introduce the reader to the first steps in building an agent-based model.

In building a model to explore how the germs might be spread on a playground we answered following design questions:

  • What are the questions that we are trying to answer?
    • How quickly do germs spread among children in a playground depending on how many children are infected to start with
  • What are the agents?
    • Individual children. A set of infected children and the uninfected children at the beginning of a recess period
  • How will we specify the agent behaviors?
    • Agents move about the playground in a random pattern and come close to other agents
  • How will we specify the agent interactions?
    • Children will move about the playground and will come close to each other based on their random moves. The germs will be spread if an infected child comes within a radius of 1 of an uninfected child.
  • What is the context?
    • A school playground at recess
  • How will they behave?
    • Each child represented by an agent in the simulation moves randomly about the playground and infected children spread germs to uninfected children who come within 1 step distance of them.

To begin building a model, start NetLogo.

NetLogo Interface Upon Starting Software.

Next, create a setup button. To do this press the “Add” button, and then from the dropdown next to this button choose the type of interface item to add by selecting “Button.” Move the cursor to the white part of the screen and click on where you would like the button to be located (Figure below).

Interface for Adding a Button.

Fill in the Display name which is the label that will be displayed on the button and the Commands which will be setup which is the name of the procedure that we will create in the Code. NetLogo shows in yellow that we have not yet created the setup procedure that will be run when the Setup button is pressed when the user is ready to run the model (Figure below).

Adding the “setup” button.

NetLogo displays the message that nothing named SETUP has been defined. Now, go to the “Code” tab and create a “setup” procedure. In some versions of NetLogo, the “Code” tab is labeled “Procedure.”

Source Code for “setup.”

The commands that need to be inserted into the code are shown in the following block.

breed [uninfectedchildren uninfectedchild]
breed [infectedchildren infectedchild]
to setup
  Set-default-shape uninfectedchildren "face happy"
  create-uninfectedchildren numberofuninfectedchildren
    set color white
    set size 1.5
    setxy random-xcor random-ycor
  set-default-shape infectedchildren "face sad"
  create-infectedchildren initialinfectedchildren
    set color red
    set size 1.5
    setxy random-xcor random-ycor

We now walk through the statements in this block of code. Before we can create the procedure, we must specify the breeds.



keyword is used to specify different types of turtles (agents).

breed [plural-name -of-breed singular-name-of-breed]

The two breed types of agents that are to be used in this model are:

  • uninfectedchildren
  • infectedchildren

and are declared with the two statements:

breed [uninfectedchildren uninfectedchild]
breed [infectedchildren infectedchild]

The “Setup” procedure begins with

to setup

The procedure ends with the command


The commands between these two statements are executed when the “Setup” button is pressed by the user.



command removes all turtles and all variables. This clears out all results from the previous run so that the next run starts anew.


This command sets the shape of the agents of breed uninfected children. We have chosen to represent them with the predefined shape “face happy.” The predefined turtle shapes are found under the “Tools” menu choice by selecting the “Turtle Shape Editor.”

Set-default-shape uninfectedchildren "face happy"

The next statement creates the appropriate number of agents or turtles of each of the defined breeds.

create-infectedchildren initialinfectedchildren 
    set color white
    set size 1.5
    setxy random-xcor random-ycor

The commands within the brackets are executed for each of the created agents. Their colors are set to white, and their size is set to 1.5 times the default size of the NetLogo turtles. The


command will move the turtle to the position described by the




reported by the execution of





The following creates the appropriate number of



The number will be defined in a variable called


which we will define as we proceed through this example. The color, size, and location are defined as described for the



create-infectedchildren initialinfectedchildren
    set color red
    set size 1.5
    setxy random-xcor random-ycor

The following counter resets the “tick counter” to zero so that the simulation begins at time zero.

reset ticks



procedure references two variables which have not yet been defined:




, which we will set up to be used as changeable parameters. For each of these variables we will create a slider bar on the interface, which will allow a user to set those variables. A user can experiment with different values for those parameters to see how the results change.

Switch to the “Interface” tab

Add a slider bar by pressing the “Add” button then selecting “Slider.” Fill in the entries for the slider bar as shown in the following Figure below.

Adding Slider Bar for “numberofinfectedchildren.”

You can right click on any of the interface elements and select “select” to be able to move that element in the interface. On macs, hold the control button and click on the interface element to edit, select, or delete. You can select “edit” to be able to change the settings associated with that element. Right click on the interface element again and select “unselect” to be able to go on with the next steps in building your agent-based model.

Now, add another slider bar to allow the user to set the variable


(Figure below).

Both Slider Bars Added.

You can now experiment with setting the sliders and pressing the setup button to see how the partial model reacts. Using descriptions of other commands in the NetLogo User Manual you can experiment with changing some of the values and commands.

Now add a “go” button that will allow the children (agents) to move about the playground in the model (Figure below).

Adding the “GO” button

Check “Disable until ticks start” which will disable the “GO” button until after the Setup procedure has been run. The “GO” button will be a “forever” button, so check the “forever” box. A forever button executes the procedure continuously. The procedure can be stopped by pressing the button again.

Now we need to write a “go” procedure that executes when the “GO” button is pushed. Select the “Code” tab.

The “go” procedure executes a loop, which runs for 100 ticks. It executes the


procedure, increments the tick counter, and goes to the top of the loop to see if the number of ticks is greater than or equal to 100. If it is, the


procedure stops. In our model this represents the length of time that the children are playing on the playground.

to go 
  if ticks >= 100 [ stop ]
to move-turtles
  ask turtles [
    right random 360
    forward .5



procedure executes every time it is referenced in the


procedure loop.


ask turtles

command specifies that the statements within the brackets should be execute for every turtle or agent in the model.



procedure causes each turtle to execute the following three commands:

The command

right random 360

has a turtle turn right some number of degrees as chosen by the NetLogo built-in function



The number of degrees will be between 0 and 359.

The command

forward .5

has the turtle move forward .5 steps.

  • Try experimenting with changing the command right to left
  • Try changing the forward .5 to back .5
  • Try changing the step size from .5 to 1 or to 2

The command


has the turtle execute the


procedure described in the following paragraph.



procedure begins with the line

To infect-playmate

and ends with the




ask infectedchildren

command instructs each turtle of breed


to execute the statements within the outer set of brackets.

to infect-playmate
  ask infectedchildren
  [ask uninfectedchildren in-radius 1
    [set breed infectedchildren
      set color red]



asks all of the uninfected children within a radius of 1 step from that


to perform the two steps with the next set of brackets.

  • Set its breed to

    (changing its shape to the sad face).

  • Set its color to red (Figure below).

Completing the Source Code.

Now experiment with setting the slider bars with the


(try using the value 30) and the


(try using the value 2). Press the “Setup” button and see that the 30 uninfected children and 2 infected children appear in the playground.

  1. Go back to the “Interface” tab.
  2. Below the “View Updates” label, select “on ticks.” NetLogo will update the view once every tick.
  3. Press the “GO” button and watch as uninfected children who come very close to the infected children become infected (Figure below).

Simulation in Action.

Let's add a monitor to the interface and set it up to display the number of infected children (Figure below).

Adding a Monitor Button for “infectedchildren.”

This playground has the oddity that the topology wraps. That is, if an agent moves off of the edge of the space, it appears on the opposite edge.

We can disable wrapping by clicking the “Settings” button on the toolbar to show the “Model Settings” dialog, and unchecking the wrapping boxes (Figure below). This will keep the agents (children) inside the playground in a way that represents the physical world more realistically.

Interface for the Simulation Settings.

Run the model again and notice that the agents no longer wrap.

We have demonstrated the approach to building a very simple model by showing how the interface can built, and the supporting procedures that can be supplied in the “Code” tab. We have introduced a few of the basic NetLogo concepts, including the concepts of ticks and breeds. We have seen how agents can move about the simulation space and how they can interact and change based on these interactions. Much more is to be learned through exploration of the NetLogo examples, and details are provided in the NetLogo User Manual.

System Dynamics

A dynamical system is, at the simplest level, just a collection of two or more things that interact with one another. System dynamics provides an approach to analyzing and developing models that represent the dynamic behavior of such systems over time. It includes representations of feedback loops and time delays that affect the behavior of the entire system. Feedback loops allow for the system to adjust its behavior based on the measured output of the system. The objects being modeled with their behaviors, interactions and relationships are considered as a system composed of interdependent components. The system dynamics modeling approach requires the modeler to decompose the system into components and define the connections and interactions among individual elements. System dynamics provides techniques and tools for representing the interconnections and behaviors of system elements.

System dynamics is also the name of a modeling and simulation paradigm, which has a visual programming interface and an underlying computational capability. Several tools, such as Stella (http://www.iseesystems.com/), Powersim (http://www.powersim.com) and Vensim (http://www.vensim.com/), are available to support system dynamics modeling. The modeler can select system elements using a graphical interface and supply connections that represent actions on and interactions between elements. The modeler defines mathematical expressions that will be used to calculate the values of elements over time. System dynamics models are executed to explore possible outcomes of a situation given varying assumptions and inputs.

The common system dynamic symbols are shown in Table below. In a system dynamics model, a “stock” is used to represent any entity that accumulates or depletes over time. A “flow” represents the transfer of contents between stocks or into/out of a stock and is defined as the rate of change of a stock over time.

Common System Dynamics Symbols
Symbol Term
Stock: Any entity that may accumulate or deplete over time
Flow: transfer of entities between stocks(rate of change of a stock)
Influence: shows a causal relationship between any two variables. Colors often indicate positive (blue) vs. negative (red) correlation.
Delay: modifies an influence to shows delay between two causally related variables
Cloud: represents entities that leave or enter the space being modeled

A simple system dynamics example is the growth and decline of a population of individuals, shown in Figure below.

Stocks and Flows in System Dynamics.

In Figure above, “Population” is shown as a stock, with a flow representing “Birth” (inflow) that increases the stock’s quantity, and a flow representing “Death” (outflow) as the removal of elements from the population stock.

Models of dynamical systems may require the representation of feedback loops. Feedback is the use of the results of past performance of a system to influence, control or modify future performance4. Figure below shows the population model with a feedback loop, which shows that the number of births in a given time interval increases as the population grows. This is called a causal relationship, since as population grows the number of potential parents increases, increasing the number of births. This is called a positive or reinforcing feedback loop since increases in the population lead to increases in the number of births.

Population model with feedback.

An example of a negative feedback loop is shown in Figure below representing the availability of gasoline in a vehicle. The arrow from the stock labeled “Gasoline in Tank” to the flow labeled “Purchase” is a feedback loop. When the gasoline level is below some threshold set in the flow, the decision is made to purchase more gasoline and the amount of gasoline in the tank is increased. This is a negative or “balancing” loop since the system reacts to counteract the low value of gasoline in the tank.

Simple gasoline model.

In some situations, the system is more accurately represented by a feedback loop as shown in Figure below. This diagram shows an arrow with a delay symbol representing a time delay between the actual gasoline level and the perceived level of gasoline in the tank. The purchase will happen after the shortage is perceived by the system.

Gasoline model with a time delay.

System dynamics models can be extended to include auxiliary causal relationships, as shown in Figure below. These models usually include auxiliary variables that show elements of a system that are not stocks or flows. These variables, along with the stocks and flows, help to represent the complexity of the system.

A System Dynamics fragment representing population growth and its related causal variables.

Flows are the rate-of-change of the stocks to which they are attached, that is, the value of a stock equals the initial value of the stock plus the sum over time of all of the inflows minus the sum over time of all the outflows. As you can see from the graphical representation, a variable is dependent on any other variable that is causally linked to it. The value of each variable is determined by a mathematical expression that contains all of the other variables upon which it is dependent. System dynamics software generally requires the modeler to supply those quantitative relationships as a part of building the model.

Figure above shows population growth dependent on the availability of food, the desire to raise children, the quality of healthcare and the level of violence in the society. These are just examples of variables that may affect population growth. One could imagine other examples of variables that could impact population growth. When building a model, the modeler chooses the variables most important to the aspects of the real world system. One of the great values of modeling and simulation using the system dynamics paradigm is allowing the modeler to explore the impact of different variables by examining their values at specific times during execution and doing what-if analysis to see how the simulation outcomes change when the values of those variables are changed.

Definition of flows in the population model.

To complete an executable model of the simplified population model, Figure above shows the mathematical expressions that will be used to calculate the values of the system elements over time. A system dynamics tool such as Stella allows the modeler to define the mathematical expressions through an input box in the user interface.

Example definitions are as follows:

  • Birth = Population * Birth Fraction
  • Death = Population * Death Fraction

Birth Fraction is a variable that is used to calculate the number of births in a given time interval based on the population size. Death Fraction is a variable used to calculate the number of deaths. The unit for Birth Fraction is births per member of the population at any given time, and the unit for death fraction is deaths per member of the population at any given time. Birth Fraction and Death Fraction are values of variables that will be input to the system by the modeler at the time the model is run. When the user prepares to execute the model, an initial value for the population as well as values for the variables Birth Fraction and Death Fraction must be specified. The model then generates a graph showing the value of Population at each point in time over the time period explored by running the simulation.

This section has provided a brief introduction to system dynamics modeling. We have introduced the basic elements of stocks and flows to represent entities that accumulate and deplete over time and the transfer of entities into and out of stocks. We have introduced the concepts of positive and negative feedback loops and the concept of representing a time delay within a feedback loop. We showed how auxiliary variables can be used to extend a model. Finally, we briefly explained the completion of a simple model by supplying the mathematical expressions used to define the relationships among variables and the initial values used to execute the model. K-12 teachers are urged to review the Quaden and Ticofsky, and the Dianna Fisher references below. Quaden and Ticofsky give some excellent simple stock and flow models for K-5 while Fisher demonstrates examples of stock and flow for high school students.

Lesson Summary

A computer simulation is software that models the behavior of some real or imagined system over time. Simulations are categorized by the way people interact with them. Think about some commonly used simulations – a video game people interact with is a virtual simulation; a computer generated movie people watch is a constructive simulation; and a history class recreating the United Nations with class members is a live simulation. Models and simulations are becoming commonplace in everyday life; try to categorize other types of simulations, like a GPS system’s route view, a smart phone app, games, or a school play.

In its simplest form, a simulation must model two things: time and behavior. Common simulation paradigms used to represent time and behavior of systems include discrete-event simulation, continuous system simulation, agent-based simulation, and system dynamics. Discrete-event and continuous simulations are the foundation for how time flows in a simulation. Discrete-event assumes time jumps from point to point based on when an event occurs. Events in the simulation are assigned a time stamp according to when they occur; when the event is processed time advances (or jumps) to that time stamp – there is no concept of time flow between these time steps. As a result, a discrete-event simulation can simulate a long period of time for a system (e.g., one week of operation of a gas station) in a very short period of computer time.

A continuous simulation is almost the same as a discrete simulation with a very small step size, but small step sizes can result in very long computer run times (because you are not jumping from event to event, but simulating every time point between the events). Scale models, equivalent models, and numerical approximations are three continuous-time modeling and simulation approaches. Numerical approximations are conducive to computer simulation while the other two methods are not. First-order continuous simulations approximate functions using Euler’s method (trapezoidal approximation) and higher-order continuous simulation techniques approximate the integral with more accuracy.

Agent-based simulation and system dynamics are commonly used approaches for modeling behavior. Agent-based simulation is based on the idea of representing the actions and interactions of autonomous agents to understand the effect the agents’ behavior has on the system as a whole. For example, what happens when one car stops in the middle of a busy road during rush-hour traffic? Instead of representing individual agents, system dynamics is based on the idea of representing the behavior of the whole system (e.g., rush hour traffic as a system). It uses feedback loops and time delays to show how the system's structure affects its behavior over time. Since agent-based simulation and system dynamics are more focused on how to model behavior, they can use either discrete-event or continuous time approaches for managing time.

Now think about the simulations mentioned in the first paragraph – how do you think they manage time and represent behavior? Since live simulations use real people and real systems, time isn’t managed but flows according to a wall clock, and people role-playing the simulation represent behavior. What about the other examples? Can you associate a simulation paradigm with them?

Further Reading / Supplemental Links

Points to Consider

  • Random number generators were discussed with discrete-event simulation; how else are random effects in real-world systems handled in simulation?
  • Can randomness help us better understand real world systems?
  • How can we use random number generators and multiple simulation runs to help us analyze the behavior of real world systems?


2Also called “analog” computing.

3Wilensky, U. 1999. NetLogo. http://ccl.northwestern.edu/netlogo/. Center for Connected Learning and Computer-Based Modeling, Northwestern University. Evanston, IL.

4 While feedback can be used to purposely control a system by the engineer, it also can just be an inherent property of the system – such as population feeds back to birthrate to determine number of births.

Notes/Highlights Having trouble? Report an issue.

Color Highlighted Text Notes
Show More

Image Attributions

Show Hide Details
Date Created:
Jul 27, 2012
Last Modified:
Apr 29, 2014
Save or share your relevant files like activites, homework and worksheet.
To add resources, you must be the owner of the section. Click Customize to make your own copy.
Please wait...
Please wait...
Image Detail
Sizes: Medium | Original