Modeling Cycle

[MKLau]

http://press.princeton.edu/chapters/s9639.pdf

[MKLau]

[MKLau]

Problem: Let us consider a simple, but not trivial, example: Did you ever search for mushrooms in a forest? Did you ask yourself what the best search strategy might be? If you are a mushroom expert, you would know how to recognize good mushroom habitat, but let us assume you are a neophyte. And even the mushroom expert needs a smaller-scale search strategy because mushrooms are so hard to see—you often almost step on them before seeing them. You might think of several intuitive strategies, such as scanning an area in wide sweeps but, upon finding a mushroom, turning to smaller-scale sweeps because you know that mush­ rooms occur in clusters. But what does “large” and “small” and “sweeps” mean, and how long should you search in smaller sweeps until you turn back to larger ones? Many animal species face similar problems, so it is likely that evolution has equipped them with good adaptive search strategies. (The same is likely true of human organizations searching for prizes such as profit and peace with neighbors.) Albatross, for example, behave like mush­ room hunters: they alternate more or less linear long-distance movements with small-scale searching (figure 1.1). The common feature of the mushroom hunter and the albatross is that their sensing radius is limited—they can only detect what they seek when they are close to it—so they must move. And, often the items searched for are not distributed randomly or regularly but in clusters, so search behavior should be adaptive: it should change once an item is found. When thinking about a model of a mushroom hunter (or albatross), we intuitively went through a series of tasks. Scientific modeling means to go through these tasks in a system­ atic way and to use mathematics and computer algorithms to rigorously determine the conse­ quences of the simplifying assumptions that make up our models.

Modeling: Being scientific always means iterating through the tasks of modeling several times, because our first models can always be improved in some way: they are too simple or too complex, or they made us realize that we were asking the wrong questions. It is therefore useful to view modeling as iterating through the “modeling cycle” (figure 1.3). Iterating does not mean that we always go through the full cycle; rather, we often go through smaller loops, for example be­ tween problem formulation and verbal formulation of the model. The modeling cycle consists of the following tasks:

1. Formulate the question. We need to start with a very clear research question because this question then serves as the primary compass and filter for designing a model. Often, for­ mulating a clear and productive question is by itself a major task because a clear question requires a clear focus. For complex systems, getting focused can be difficult. Very often, even our questions are only experimental and later we might need to reformulate the ques­tion, perhaps because it turned out to be not clear enough, or too simple, or too complex. The question in our Mushroom Hunt model is: What search strategy maximizes the rate of finding items if they are distributed in clusters?
2. Assemble hypotheses for essential processes and structures. Agent-based modeling is “naive” (DeAngelis et al. 1994) in the sense that we are not trying to aggregate agents and what they are doing in some abstract variables like abundance, biomass, overall wealth, demo­ graphic rates, or nutrient fluxes. Instead, we naively and directly represent the agents and their behavior. We create these agents, put them in a virtual environment, then let the vir­ tual world run and see what we can learn from it. (It is important, though, to ask ourselves: is it possible to answer our question using a more aggregated and thus simpler model?) Usually we have to formulate many hypotheses for what processes and structures are essential to the question or problem we address. We can start top-down and ask ourselves questions such as: What factors have a strong influence on the phenomena of inter­ est? Are these factors independent or interacting? Are they affected by other important factors? We might draw so-called influence diagrams, or flow charts, or just caricatures of our system and question. But whatever technique we prefer, this task has to combine existing knowledge and understanding, a “brainstorming” phase in which we wildly hypothesize, and, most importantly, a simplification phase. We have to force ourselves to simplify as much as we can, or even more. The modeling cycle must be started with the most simple model possible, because we want to develop understanding gradually, while iterating through the cycle. A common mistake of begin­ ners is to throw too much into the first model version—usually arguing that all these factors are well known and can’t possibly be ignored. Then, the answer of the modeling expert is: yes, you might be right, but—let us focus on the absolute minimum number of factors first. Put all the other elements that you think might need to be in the model on your “wish list” and check their importance later. The reason for this advice is this: just our preliminary understanding of a system is not sufficient for deciding whether things are more or less important for a model. It is the very purpose of the model to teach us what is important. So, it is wise to have a model implemented as soon as possible, even if it is ridiculously simple. But the simpler the model is, the easier it is to implement and analyze, and the sooner we are productive. The real productive phase in a modeling project starts when we get the modeling cycle run­ ning: assumptions—implementation—analyses—interpretation—revised assumptions, and so on. It is difficult to formalize this task of the modeling cycle. One important help is heu­ ristics for modeling: rules of thumb that are often, but not always, useful for designing models. We point out these heuristics throughout this book; use the index to find them. Compilations of modeling heuristics can be found in Starfield et al. (1990) and Grimm and Railsback (2005, chapter 2). And—in part III of this book we present pattern-oriented modeling, a very important strategy for formalizing both this and the next step in the modeling cycle. For the Mushroom Hunt model we assume that the essential process is switching between relatively straight large-scale “scanning” movement and small-scale searching, depending on how long it has been since the hunter last found an item.
3. Choose scales, entities, state variables, processes, and parameters. Once we choose some simplifying assumptions and hypotheses to represent our system of interest, it is time to sit down and think through our model in detail. We thus produce a written formulation of the model. Producing and updating this formulation is essential for the entire modeling pro­ cess, including delivery to our “clients” (our thesis committee, journal reviewers, research sponsors, etc.). In chapter 3, we will start using a very helpful protocol for doing this. This step, for the Mushroom Hunt model, includes specifying how the space that hunters move through is represented (as square grids with size equal to the area the hunter can search in one time step), what kinds of objects are in the model (one hunter and the items it searches for), the state variables or characteristics of the hunter (the time it has hunted and the number of items it has found, and the time since last finding an item), and exactly how the hunter searches. (Full details are provided when we imple­ ment the model in chapter 2.)
4. Implement the model. This is the most technical part of the modeling cycle, where we use mathematics and computer programs to translate our verbal model description into an “animated” object (Lotka 1925). Why “animated”? Because, in a way, the implemented model has its own, independent dynamics (or “life”), driven by the internal logic of the model. Our assumptions may be wrong or incomplete, but the implementation itself is— barring software mistakes—always right: it allows us to explore, in a logical and rigorous way, the consequences of our assumptions and see whether our initial model looks useful. This task often is the most daunting one for neophytes in modeling, because they usu­ ally have no training in how to build software. Thus, our claim that the implementation always is “right” might sound ironic to beginners. They might struggle for months to get the implementation right—but only if they don’t take advantage of existing software plat­ forms for agent-based modeling. With the platform that we use in this book, NetLogo, you can often implement simple ABMs within a day or two, including the time to test your code and show that it is accurate. So please don’t panic!
5. Analyze, test, and revise the model. While new modelers might think that designing a model and implementing it on the computer takes the most work, this task—analyzing a model and learning from it—is the most time-consuming and demanding one. With tools like NetLogo you will learn to quickly implement your own ABMs. But doing sci­ ence with ABMs requires much more. Much of this book will be devoted to this task: how can we learn from our models? In particular, we will try to put forward the research program of “individual-based ecology” (Grimm and Railsback 2005) and apply it to other sciences. This program is dedicated to learning about the real world: we do not just want to see what happens when we create some agents and make up their behaviors—we want to see what agent behaviors can explain and predict important characteristics of real systems. To answer the mushroom hunting question, we could analyze the model by trying a variety of search algorithms and parameter values to see which produces the highest rate of finding items.