Paradigms
This tutorial is an updated version of the original tutorial described in Andrade et al. (2015). It works with TerraME version 2.0.0-RC4 or greater.
A model is generally understood as a purposeful and simplified representation of some system or any other aspect of the real world (Starfield et al., 1993). There are many types of models, including, among others, verbal, mathematical, and graphical representations. Building models is a well-known way of improving our understanding of the world. Computational simulation is a particular type of model. Unlike mathematical models, simulations are run rather than solved. Therefore, by overcoming many limitations imposed by mathematical tractability, simulation models allow researchers to address issues that require less simplified representations of the world (Railsback, Grimm, 2011). Such models introduce new possibilities to investigate coupled natural and human systems, including the ability of simulating the emergence of complex behaviors from relatively simple activities.
There are different world views, also called paradigms, to develop computational models for coupled natural and human systems. The system under study is then represented with the definitions available for that paradigm. The modeler needs to take into account the advantages and the limitations of the available paradigms in order to choose one that best addresses the problem under study. This tutorial explores three modeling paradigms: Systems dynamics, Cellular automata, and Agent-based modeling, which are presented as follows.
System dynamics is the most basic paradigm upon which all others are based. This paradigm starts from the assumption that a system under study can be isolated from the rest of the world. In this sense, we would have only linear dynamics between the system and the rest of the world. If the dynamics is not linear, it would need to be simplified to a linear dynamics or to be included in the model.
This paradigm views the world as a set of stocks and flows, assuming that everything that can be measured can also be modelled (Ford, 1999). Stocks can be anything, from the area covered by a lake to the number of individuals that have a given disease, from the amount of carbon stored in the atmosphere to the fat of a body. Flows describe mathematically how to transform or move stocks, making the system dynamic. They can connect two stocks, a stock with itself, or a stock with the external world, being always directed (Angerhofer and Angelides, 2000). One or more flows can build a feedback loop that allows the system to present complex behavior. A model of System dynamics usually has two or more feedbacks that compete with each other to control the simulation.
Using System dynamics models, it is possible to work with what-if scenarios to investigate the behavior of the system according to changes in its inputs or even changes in its internal behavior (Stave, 2003; Meadows et al., 1972). These scenarios might be developed from scratch, can be result of proposed public policies (Stave, 2002; Ghaarzadegan et al., 2011), or based on outcomes of other models such as the ones developed by IPCC (Field et al., 2014). One important property these scenarios can investigate is whether the system is capable of adapting itself to exogenous changes, keeping its internal state stable. This property is called homeostasis.
The main disadvantage of this paradigm comes from its simplicity in representing the world as stocks. Individuals have to be aggregated in quantities, percentages, or averages. Space is constrained to measures of volume or area, with everything distributed homogeneously within the study area. The connections between stocks cannot change along the simulation. These constraints can be feasible in some studies, but they might become too much restricting if the spatial distribution of stocks is important to the problem under study, of when individuals need to take their own decisions autonomously. These constraints are relaxed by the next paradigms.
The Cellular automata (CA) paradigm views the world as a space with a finite set of two-dimensional discrete and contiguous cells (Von Neumann, 1966). Each cell has a homogeneous internal con- tent, which includes zero or more stocks and an internal state machine, called automaton. The simulation then runs as a sequence of discrete steps. In each step, the automaton state changes according to transition rules, defined based on its own state and the state of its neighbors. These changes occur in parallel in space, which means that, when a cell changes its state in a given time step, this change cannot cause any effect in the decision of the other cells in the same time step.
The Neighborhood is an important concept for CA, since it determines the interaction between the elements that build up the model (Hagoort et al., 2008). If two cells are neighbors, it means that one exerts some sort of influence over the state of the other. Depending on the process being modelled, the neighborhood can be homogeneous or heterogeneous in space. Examples of homogeneous neighborhoods are the well-established von Neumann and Moore Neighborhoods. However, in some cases, these neighborhoods are not enough to represent the complexities of the spatial relations, which may demand, for example, the definition of neighborhoods that include transportation networks.
This paradigm has become increasingly popular among environmental modelers because of its ability to simulate complex spatial patterns that emerge from simple parallel local interactions between neighboring cells (Couclelis, 2000; Wolfram, 1984). In addition, due to its explicit spatial representation, it has a direct compatibility with geospatial representations of the world used by Geographic Information Systems (GIS). During the last decades, it has been widely used in the studies of phisical processes (Hesselbarth and Gobel, 1991) and social process, like urban dynamics (Batty and Xie, 1994; Batty, 2007; Clarke and Gaydos, 1998) and epidemiology (Medeiros et al., 2011; Slimi et al., 2009).
Despite its ability to simulate the emergence of complex spatial patterns from simple local rules, the main disadvantage of this paradigm comes from the impossibility of representing mobile objects, once the cells are fixed in space. Models that use CA to study human behavior need to anthropomorphise the state variables of a cell, simulating human behavior as a physical processes. However, these adaptations might not be enough to represent the complexity of human behaviour.
The Agent-based modeling (ABM) paradigm views the world as multiple autonomous agents interacting within an environment. Agents can be understood as entities "situated within and a part of an environment, that senses that environment and acts on it, over time, in pursuit of its own agenda" (Franklin and Graesser, 1997). This definition emphasizes agent’s features that have been conventionally identified as important: autonomy, social ability, reactivity, and proactivity (Wooldridge and Jennings, 1995). First, like CA, agents are autonomous. They are a separate locus of control, fully responsible for their actions and in charge of accomplishing their role. Although centralized authorities may exist as environmental constraints, there is no global or external flux of control dictating the agent’s actions. This self-organization of autonomous agents is what promotes the emergence of global patterns from the bottom-up (Macy and Willer, 2002). Second, agents have social ability and are able to interact with each other. Third, agents are reactive and capable of responding to stimuli coming from their environment. Finally, agents are proactive, which means that they exhibit goal-directed behavior by taking their own initiative (Wooldridge and Jennings, 1995; Zamboneli et al., 2001).
The environment defines a space in which agents operate, serving as a support to their actions. The meaning and role of an environment depends on the system that is being modeled. In some situations, it may be neutral, with minimal or no effect on the agents or, in analogy to the real world, the environment may have an active role in providing the context for agents to perform their actions, to acquire information about the problem they have to solve, and to communicate with each other (Gilbert, 2008; Weyns, Schumacher et al., 2005). In the latter case, the environment can be specified as an independent piece of software, such as CA, that encapsulates its own roles, including particular characteristics and dynamics that directly influence the agent's behavior and the emergence of complex structures (Gilbert, 2008; Weyns et al., 2005).
Interactions are also fundamental for an ABM, as they represent the main feature that distinguishes ABM from other paradigms. The agents’ potential to locally interact with each other and their environment is the key to the simulation of the emergent properties of complex systems (Axelrod, 2003; Holland, 1998). For this reason, all ABM include some sort of interaction that involves transmission of knowledge or materials that can affect the behavior of the recipients (Gilbert, 2004). The nature and sophistication level of these interactions may vary substantially depending on the roles assumed by the agents in a simulated system. In some cases, agents interact by simply perceiving the presence of their pairs in the surroundings, while other situations demand interactions based on the development and use of complicated communication means (Gilbert, 2008; Zambonelli et al., 2001). In general, ABM can present direct agent-agent interactions, indirect agent-agent interactions, and agent-environment interactions.
The agent-based modeling paradigm separates the spatial representation from the individuals that take decision, which makes it more complex than the other two paradigms. It means that this paradigm is particularly powerful for representing the complexity of coupled natural and human systems, but also more challenging and time consuming in terms of development.
This section presents a short tutorial based on the course introduced in last section. We describe one model for each of the three modeling paradigms, implement them in TerraME, and investigate their outcomes.
The first model of this tutorial was initially proposed by Meadows (2008). It is called water in the tub. This very simple model uses System Dynamics to describe how water flows out of a tub. Initially the tub is filled with 40 gallons of water. During the simulation, water flows out of the tub at a constant rate of 5 gallons per second. The idea is to implement a model to simulate the amount of water in the tub over time.
In TerraME, a stock is described as a variable within a Model.
The code below shows a declaration of a Model named Tub in TerraME with three attributes: water, flow, and finalTime. Note that the source code does not represent units of measurement explicitly. It is up to the modeler to define that a given stock is measured as gallons, liters, or any other unit, using or converting it accordingly when defining flows. In the case of Tub, water and flow are measured in gallons, while finalTime is measured in seconds.
Tub = Model{
water = 40,
flow = 5,
finalTime = 8,Next we need to describe how the simulation changes stocks in each time step. It simply reduces the amount of water in the tub according to flow. This function takes the model itself as argument and uses the operator . to access its variables.
execute = function(model)
model.water = model.water - model.flow
end,We need now to indicate how the stock will be observed along the simulation.
TerraME has a concept of Chart to plot the attributes along the simulation. We then select attribute "water" of the model to be visualized.
init = function(model)
model.chart = Chart{
target = model,
select = "water"
}The last concepts needed in this model are Event and Timer. Event is a time instant when the simulation engine executes operations. It contains a function named action that describes part of the behavior of the Model. Timer is a type that registers, manages, and executes a set of Events over time. It manages an Event queue ordered according to their priorities and timestamps. We create two Events: one to execute the model and the other to update model.chart.
model.timer = Timer{
Event{action = model},
Event{action = model.chart}
}
end -- init()
} -- TubTo run the simulation we can just call:
Tub:run()Figure below shows the output of a simulation. In the end, the amount of water in the tub is zero as five gallons of water are removed from the tub each time step.
Note that, if we run the model until a time greater than eight, the simulation would produce a physically inconsistent output. As it keeps removing water out of the tub, the simulation will produce negative amounts of water. Therefore, this Model is correct as long as we simulate it to a time equal or less than the initial amount of water divided by the flow. Semantic problems such as this one are always up to the modeler, as the toolkit cannot identify them.
instance = Tub{
finalTime = 12
}
instance:run()
Executing the water in the tub gives the impression that time is continuous, as th Chart plots a line. However, in TerraME events are executed in discrete time steps. The default periodicity of each Event is one, therefore it removes five gallons of water from the tub at once in each time step. We can see this clearly if we reduce the observation event to a period of 0.1, which means that it will occur ten times before water is taken out from the tub. Code below describes the new Timer.
model.timer = Timer{
Event{action = model},
Event{action = model.chart, period = 0.1}
}This new implementation has the same simple behavior of the previous one, but it has a different outcome, as shown in Figure below. Instead of having a straight line that could be thought as a continuous simulation, now we have what really happens in the simulation. As the observation time is more frequent than the behavior of the model, it will observe a couple of times the same amount of water before it flows out from the tub. This is a property of discrete event simulators that needs to be taken into account when developing any model. Each model has a temporal scale that should be defined a priori. In theoretical models it is possible to reduce the time scale by reducing the frequency of the events and the amount of flows. Models that use data usually have their temporal scale constrained by the frequency of data acquisition. In any case, one should never observe the model more frequently than it changes because it will not produce any new output.
By using the idea of a system composed by stocks and flows, it is possible to develop models that can produce complex behaviors. Flows can connect different stocks as well as a stock to itself to generate feedback loops, which is the main source of complexity in systems. TerraME also has other functionalities to deal with system dynamics such as events that have different initial times and observation of different attributes of a cell at the same time.
More examples related to System Dynamics in TerraME can be found in package sysdyn.
The second example simulates fire in a forest using CA paradigm. The simulation starts with a small fire in one random cell of a forest completely filled with trees. The fire then propagates to the neighboring forest cells on and on until all the forest is completely burned. To represent this process with a CA we need to have three states: forest, burning, and burned. A forest cell will remain in this state until it finds a burning neighbor. A burning cell will become burned in the next time step, while a burned cell will not change its state anymore.
The implementation of the model starts with a definition of a Model, as presented below. Fire has two parameters, dim, representing the size in x and y dimensions, and finalTime, indicating the final simulation time.
Fire = Model{
finalTime = 50,
dim = 50,Function init must then initialize a Cell that describes the attributes and functions of each spatial partition.
Each Cell will initially have an attribute called state with value "forest". It also has an execute function to describe the behavior of the Cell in each time step, implementing the transition rules of the automaton. In this function, the Cell verifies its internal state. In the case of being "forest", it needs to check whether any neighbor is "burning". It uses a second order function called forEachNeighbor to transverse its Neighborhood. A second order function is a function that takes another function as argument. This function takes a neighbor Cell as argument and is called for each of its neighbors. If any of the neighbor cells has a burning state then the Cell also becomes "burning". Otherwise, if the state of the Cell is burning then it becomes "burned". If the state is "burned" it will not change, therefore this situation is not described in the source code.
init = function(model)
model.cell = Cell{
state = "forest",
execute = function(self)
if self.past.state == "burning" then
self.state = "burned"
elseif self.past.state == "forest" then
forEachNeighbor(self, function(neigh)
if neigh.past.state == "burning" then
self.state = "burning"
end
end)
end
end
}An important point in the description of execute is the attribute past. In a CA, the process takes place in parallel in space. In this sense, the changes in the state of the a Cell cannot affect the state of another Cell in the same time step. Because of this, we need to work with two copies of the cells, one storing the present state and the other storing the past state. TerraME allows cells to have the attribute named past with the attributes of the Cell in the previous time step. The methodology to implement a CA is then to read only from the past and write into the present. Therefore, every line that has an if uses past, while the lines that update states do not.
The next step to implement the model is to define the whole space. In TerraME, we use a CellularSpace to represent the forest. It is a set of cells representing a spatial region under study, created from a Cell and a description of its x and y dimensions, as shown in the code below. In the code, world is a CellularSpace with 2,500 cells initially with state forest. Any CellularSpace can have a Neighborhood, a set of cells defining the proximity relations of a given Cell. The CellularSpace will have a von Neumann Neighborhood, connecting each Cell to its four touching neighbors. The final step to build the initial state of the forest is to initialize one random Cell with burning state to start the fire, as shown in the last line.
model.cs = CellularSpace{
xdim = model.dim,
instance = model.cell,
}
model.cs:createNeighborhood{strategy = "vonneumann"}
model.cs:sample().state = "burning"To plot the amount of cells in each state, we need to create a Chart. We can select attribute state and plot some of its values ("forest", "burning", and "burned", in the code below).
To visualize the spatial distribution of cells, we need to define a Map. In both Chart and Map we will paint "forest" as green, "burning" as red, and "burned" as brown.
model.chart = Chart{
target = model.cs,
select = "state",
value = {"forest", "burning", "burned"},
color = {"green", "red", "brown"}
}
model.map = Map{
target = model.cs,
select = "state",
value = {"forest", "burning", "burned"},
color = {"green", "red", "brown"}
}Finally, we need to define a Timer with three Events to simulate the model. The first one synchronizes the CellularSpace, copying the current attribute values to the past, and then calls execute for each of its Cells to spread the fire. The second one updates the Chart and the third one updates the Map.
model.timer = Timer{
Event{action = model.cs},
Event{action = model.chart},
Event{action = model.map}
}
end -- init()
} -- Fire
Fire:run()Figure below shows the output of a simulation. On the top there is a Chart with the amount of Cells in each state. In the bottom
there are three images. On the left, the image describes the beginning of the simulation, when there is only one burning Cell. As it is chosen randomly, different simulations will start with a different burning Cell. In
the middle, we have the simulation after ten time steps, where the burning cells produce a square with burned cells inside. The square grows symmetrically in the four directions based on the initial burning Cell. In the right, we have the final state of the simulation. Note that executing the simulation until time 50 will not be enough to burn all the cells. If we simulate a couple more steps, the forest will still burn, but as we configured the simulation to stop in time 50 this was the final state. As the Cellularspace has 50x50 cells, the simulation will never burn all the cells in 50 steps, even if the fire starts in one of the four cells in the middle of the CellularSpace. To guarantee that all the cells will be burned we would need to run the simulation with at least 99 steps.
CA is useful when one wants to model continuous processes that take place in a given region under study. It is used to study environmental processes such as hydrology, vegetation dynamics, as well as human processes, such as deforestation or urban growth. TerraME also has functionalities to model complex CA. Some of them are database interface, creating cellular spaces stored in external sources, visualization of different attributes at the same time, and strategies to create complex neighbourhoods.
More examples related to Cellular Automata in TerraME can be found in package ca.
In the last model of this tutorial we investigate a model of population growth that explicitly represents individuals through an agent-based model. In this model, agents can move freely in space and reproduce. The idea is to see how one can describe an agent-based model and investigate whether a very simple model can produce an emergent behaviour. This model has three parameters: quantity, representing the amount of agents in the beginning of the simulation, dim, describing the spatial dimensions, and finalTime.
GrowingSociety = Model{
quantity = 10,
dim = 100,
finalTime = 120,The central concept in TerraME to work with ABM is the idea of Agent. It is an autonomous individual that can have a set of attributes, relations with other agents as well as with spatial partitions, and autonomy to take decisions. The Agent in the population growth model has a single function execute that describes its behavior, as shown in the code below. First, it selects a random empty Cell from the neighborhood using emptyNeighbor(). This function returns nil if there is no empty neighbor. If there is an empty neighbor, then with 30% of probability it reproduces and puts its child there. To implement this we use a sample() over a Random using a probability p of 0.3. After that, the Agent tries to get a random neighbor Cell to move, leaving the previous Cell empty. Note that if the Agent is fully surrounded by other agents it cannot take any action.
init = function(model)
model.agent = Agent{
execute = function(self)
local cell = self:emptyNeighbor()
if cell and Random{p = 0.3}:sample() then
local child = self:reproduce()
child:move(cell)
end
cell = self:emptyNeighbor()
if cell then
self:move(cell)
end
end
}The next step of the population growth model is to define a Society of agents. It is a set of agents with the same general behavior and attributes. This Society will have ten agents and an instance describing the overall behavior of its agents, which is the Agent that we have just defined. Every time an Agent inside a Society reproduces, the newborn will be automatically added to the same Society of its parent.
model.soc = Society{
instance = model.agent,
quantity = model.quantity
}The ten agents will be placed in a 100x100 CellularSpace with a Moore neighborhood, connecting a Cell to its eight surrounding cells. The CellularSpace also has an instance, which is a Cell with a function called state. It returns "full" if there is an Agent inside of it. Otherwise it returns "empty". This function will be used to create a Map.
model.cell = Cell{
state = function(self)
if self:isEmpty() then
return "empty"
else
return "full"
end
end
}
model.cs = CellularSpace{
xdim = model.dim,
instance = model.cell
}
model.cs:createNeighborhood()To connect the agents to the cells we need an Environment, which aggregates space and behavior. In this model, we will create a random placement of agents with at most one Agent per Cell, as shown in the code below.
model.env = Environment{
model.cs,
model.soc
}
model.env:createPlacement()Before running the simulation we need to define a Map and a Chart, one to see the spatial distribution of agents and the other to see the amount of agents, respectively. When a Map observes a function instead of a value, it shows the output of the function in each Cell . A Chart over a Society as default observes the number of agents along the simulation.
model.map = Map{
target = model.cs,
select = "state",
value = {"full", "empty"},
color = {"black", "white"}
}
model.chart = Chart{
target = model.soc
}Then we declare a Timer to execute the Society. When the action of an Event is a Society, it executes all its agents. We also need two events to update map and chart.
model.timer = Timer{
Event{action = model.soc},
Event{action = model.map},
Event{action = model.chart}
}
end -- init()
} -- GrowingSociety
GrowingSociety:run()The evolution of the simulation is quite simple, with the spatial distribution of agents along the simulation shown below. As agents can move randomly, there is always a heterogeneous distribution of agents around the areas where the first agents were placed in the beginning of the simulation. We can see that if we simulate for more a couple of time steps the population will fill all available cells, reaching a stable state where nobody can reproduce or move.
Although very simple, this model generates an emergent behavior. Figure below summarizes the amount of agents along the simulation. We can see that the population grows according to a logistic curve. In the beginning, it has an exponential growth until around time 40 as there are no spatial constraints. As the model evolves, it becomes more and more difficult to reproduce because the neighborhood is full or because the border of the CellularSpace was reached, until the population reach the stable state. Note that this constraint is not explicitly represented in the model, but it emerges from the individual decisions of the agents along the simulation.
This model is non-deterministic, which means that every time it is simulated it will produce a different outcome. In this situation, it is always interesting to repeat the simulation and perform statistical analysis about the stability of the results. Despite its randomness, running this model different times will produce similar outcomes.
Agent-based modeling has no limits in terms of what can be represented. Agents can be any autonomous decision making entity. They can have a complex internal representation, message passing strategies, belong to social networks, and have multiple placements, among other capabilities. TerraME has functionalities to deal with all these challenges.
More examples related to Agent-Based Modeling in TerraME can be found in package logo.
Andrade, P. R., Camara, G., Maretto, R. V., Monteiro, A. M. V., Carneiro, T. G. S., Feitosa, F. F. (2015) Experiences with a Socio-Environmental Modeling Course. Modelling in Science, Education and Learning Volume 8(1), 2015 doi: 10.4995/msel.2015.2811.
Angerhofer, B. J., Angelides, M. C. (2000). System dynamics modelling in supply chain management: 456 research review. Simulation conference, 2000. Proceedings. Winter (Vol. 1, pp. 342-351).
Axelrod, R. (2003). Advancing the art of simulation in the social sciences. Japanese Journal for Management Information System, 12(3), 3–16.
Batty, M. (2007). Cities and complexity: understanding cities with cellular automata, agent-based models, and fractals. The MIT press.
Batty, M., Xie, Y. (1994). From cells to cities. Environment and planning B, 21(7), 31–48.
Clarke, K. C., Gaydos, L. J. (1998). Loose-coupling a cellular automaton model and gis: long-term urban growth prediction for san francisco and washington/baltimore. International Journal of Geographical Information Science, 12(7), 699–714.
Couclelis, H. (2000). Modeling frameworks, paradigms, and approaches. Geographic information systems and environmental modeling, 36–50.
Field, C., Barros, V., Dokken, D., et al. (2014). Climate change 2014: impacts, adaptation, and vulnerability. Volume I: Global and Sectoral Aspects. Contribution of Working Group II to the Fifth Assessment Report of the Intergovernmental Panel on Climate Change. Available from http://ipcc-wg2.gov/AR5/
Ford, F. A. (1999). Modeling the environment: an introduction to system dynamics models of environmental systems. Island Press.
Franklin, S., Graesser, A. (1997). Is it an agent, or just a program?: A taxonomy for autonomous agents. In J. Muller, M. Wooldridge, N. Jennings (Eds.), Intelligent agents III: agent theories, architectures, 4 and languages (Vol. 1193, pp. 21–35). Springer Berlin Heidelberg. Available from http://dx.doi.org/10.1007/BFb0013570
Gilbert, N. (2004). Agent-based social simulation: dealing with complexity. The Complex Systems Network of Excellence, 9(25), 1–14.
Gilbert, N. (2008). Agent-based models. London: Sage Publications.
Hagoort, M., Geertman, S., Ottens, H. (2008). Spatial externalities, neighbourhood rules and ca land-use modelling. The Annals of Regional Science, 42(1), 39–56.
Hesselbarth, H. W., Gobel, I. R. (1991). Simulation of recrystallization by cellular automata. Acta Metallurgica et Materialia, 39(9), 2135–2143. Available from http://www.sciencedirect.com/science/ article/pii/0956715191901832
Holland, J. H. (1998). Emergence: from chaos to order. Oxford University Press.
Macy, M. W., Willer, R. (2002). From factors to actors: Computational sociology and agent-based modeling. Annual Review of Sociology, 28, 143–166. Available from http://www.jstor.org/stable/3069238
Meadows, D. H. (2008). Thinking in systems: A primer. Chelsea Green Publishing.
Meadows, D. H., Meadows, D., Randers, J., Behrens III, W. W. (1972). The limits to growth: A report for the club of rome’s project on the predicament of mankind. New York: Universe.
Medeiros, L. C. d. C., Castilho, C. A. R., Braga, C., Souza, W. V., Regis, L., Monteiro, A. M. V. (2011). Modeling the dynamic transmission of dengue fever: investigating disease persistence. PLOS neglected tropical diseases, 5(1), e942.
Railsback, S., Grimm, V. (2011). Agent-based and individual-based modeling: A practical introduction. Princeton University Press. Available from http://books.google.com.br/books?id=VQOjinaRG9cC
Slimi, R., El Yacoubi, S., Dumonteil, E., Gourbiere, S. (2009). A cellular automata model for chagas disease. Applied Mathematical Modelling, 33(2), 1072–1085. Available from http://www.sciencedirect.com/ science/article/pii/S0307904X07003563
Starfield, A. M., Smith, K., Bleloch, A. L. (1993). How to model it: Problem solving for the computer age. New York, NY, USA: McGraw-Hill, Inc.
Stave, K. A. (2002). Using system dynamics to improve public participation in environmental decisions. System Dynamics Review, 18(2), 139–167. Available from http://dx.doi.org/10.1002/sdr.237
Stave, K. A. (2003). A system dynamics model to facilitate public understanding of water management options in Las Vegas, Nevada. Journal of Environmental Management, 67(4), 303–313. Available from http://www.sciencedirect.com/science/article/pii/S0301479702002050
Von Neumann, J. (1966). Theory of self-reproducing automata. Burks, A.W. (Ed.).
Weyns, D., Schumacher, M., Ricci, A., Viroli, M., Holvoet, T. (2005). Environments in multiagent systems. The Knowledge Engineering Review, 20(2), 127–141.
Wolfram, S. (1984). Cellular automata as models of complexity. Nature, 311(4), 419–24.
Wooldridge, M., Jennings, N. R. (1995). Intelligent agents: Theory and practice. The knowledge engineering review, 10(02), 115–152.
Zambonelli, F., Jennings, N. R., Wooldridge, M. (2001). Organisational abstractions for the analysis and design of multi-agent systems. In Agent-oriented software engineering (pp. 235–251).