In this series, the authors take positions on coding platforms used in agent-based modelling. In this first instalment, Ben makes an argument in favour of NetLogo. In the next episode, Iza makes the case for Python.
Let’s start with a quote from the annals of archaeological modelling:
“…traditional inferential approaches fail to capture the dynamic and co-evolutionary nature of human settlement decisions as they respond to shifting resources and the presence and actions of other people. If only we had a laboratory to study the outcomes of various processes as they might play themselves out through hundreds of years on realistic landscapes!” – Kohler et al. 1996, Agent-Based Modeling of Prehistoric Settlement Systems in the Northern American Southwest
Is this radical thinking? In archaeology, our inferences are based upon assumptions about processes which may have occurred in the past that have influenced the character of the record we record today. But are these assumptions even warranted in the first place? Do the assumed combinations of processes necessarily generate the patterns we see in the record, and under all contingencies? What are needed are tools for evaluating the ramifications of our assumptions. Time machines will only give us a small, localised part of those long histories; what we need is a “What-If Machine®”. This is why I became interested in computer simulation, and ultimately why I began learning NetLogo.
I chose NetLogo for my first forays into model-building because it was a) recommended in some of the literature of the day, b) didn’t require extensive reconfiguring of the file system, and c) FREE. In the realms of computer and social science, NetLogo has been the target of both commendation and contempt. While NetLogo continues to be used regularly in social sciences and increasingly in the natural sciences, there is a general undercurrent of disapproval from certain corners which have been detected by a number of us here at Simulating Complexity, and which spurred this series. Most of the arguments I hear against NetLogo focus on its limitations in terms of handling complex procedures, and that it just isn’t a “real” programming language. These criticisms are often vague and not lacking an elitist tone. But before I address these criticisms, I want to highlight some of the strengths of NetLogo for the purpose of building models as research tools. I think there are three primary reasons why people use NetLogo, and why its user base continues to grow:
Advantage #1 – Easy to learn
NetLogo IS dead simple to learn. Unless you’ve come up on another language, the syntax is very natural. This is why its legacy language, Logo, was chosen to teach schoolchildren the basics of programming. Additionally, there is pretty decent documentation. New books and seminars (see here and here, for examples) are appearing regularly that use NetLogo to teach simulation and agent-based modelling specifically. By my own account, I find that there are very few instances where I can’t find what I need in the NetLogo dictionary or programming guide. The documentation for many other ABM-specific platforms is typically terrible. and the documentation for more general languages can be downright incomprehensible for a novice. The centralisation of online user forums to places like Stack Exchange is helping to alleviate this, but this is also true for NetLogo as well.
Advantage #2 – Ease and speed of programming
There is a lot of stuff that NetLogo has intelligently built-in so that programming is easy and fast, not requiring a lot of overhead. As an early article (2005!) notes, a model that took up 950 lines in RePast could be written with only 50 lines in NetLogo. You don’t need to code your own GUI, defining gridspace only takes a couple of mouse clicks, and agents are an in-built feature. At our recent workshop at CAA 2014, entitled “One hour, one model”, we took a group of folks with varying degrees of programming skills and gave them a one-hour tutorial on modelling with NetLogo. Then groups worked together to build models of exchange, all groups producing within one hour a working model. It was heartening to see how NetLogo could be used in this way as a prototyping “tool to think with”.
Attendees share their models at the CAA2014 “One hour, One Model” session
There have been efforts to make other programming platforms more accessible. RePast developed its own bridging language, ReLogo, which could make use of the RePast libraries while being more user-friendly, even converting models written in NetLogo to ReLogo. There are now heaps of Python libraries aimed at ABM, which I’m sure my colleague Iza will tell you all about in Part 2. While some of these are starting to meet NetLogo on the ease-of-programming front, they’re currently lacking in documentation and user base.
Advantage #3 Ease of sharing
Because NetLogo doesn’t require specific system configurations (it’s a standalone), sharing NetLogo models is very easy. Once the programme is installed, one can open and run any NetLogo model. This includes those in online repositories, such as NetLogo’s own community library, and user generated libraries, such as O’Sullivan and Perry’s “Model Zoo” or Vidal’s Multiagent library, which provide dozens of downloadable examples of simple models that can be used as building blocks for dealing with common issues in modelling. Furthermore, models can be saved as Java applets, to be easily embedded in web pages and run using common software. This ability to quickly share ideas and modify code promotes an environment which gets closer to building and using models on the fly.
But all of these things have been said before. What about the criticisms of NetLogo? Are there real constraints posed by using NetLogo versus another language. Personally, the only place that I’ve truly felt limited in using NetLogo is the inability to run a single instance of NetLogo across multiple cores in a cluster. While BehaviorSpace, NetLogo’s in-built experiment automator, allows separate instances of the same experiment to be run on multiple cores, it is not yet possible to speed up NetLogo by spreading out the work a single simulation is doing across multiple cores. It would be nice to run faster models, but in the end, this seems like a reasonable trade-off, one that may end up being rectified. If a programmer runs into this issue, hopefully they’ll be versed enough by that time to transfer to model to a language that can be distributed across a cluster (or will know someone who can help).
If I were asked “Is there anything that can’t be done with NetLogo that can be done with other languages?”, I would have to honestly answer that I have not yet found that limit. For my purposes, which usually pertain to archaeology or anthropology more generally, I’ve been able to find a workable NetLogo solution to every problem I have ventured upon. This includes melding ABM with GIS and web-based datasets, and generating structured populations for demographic simulations. Colleagues of mine are using NetLogo regularly for network applications, and some folks are using it for good ol’ systems dynamics. I’ve even built a random name generator with it to help my wife and I choose a name for our daughter (in the end we settled on one the old fashioned way, but it worked! I’ll try to find the code..). And perhaps most exciting is that there are now add-ons for using genetic algorithms to search parameter spaces for optimal solutions. The fact is, NetLogo, through its built-in functionality and user-generated extensions, is capable of a wide range of programming.
But while that is the simple truth, the complicating fact is that there are things which NetLogo can do which are much, MUCH more easily and elegantly accomplished in other languages. The existence of NetLogo extensions to SQL, R, and other platforms is a patent recognition of this. But to argue in favour of one or the other is haggling over a matter of degrees: SHOULD you do it in another language? Maybe. CAN you do it NetLogo? Almost certainly. Asking whether one language is inherently superior to another is sort of like asking whether you can drive in a tank or a golf cart. Either can perform the task of driving from point A to point B. What matters is where you’re driving to, what you’re likely to encounter along the way, and most importantly, how comfortable you are behind the wheel.
In a roundabout way, this gets at the issue of whether our models should be complicated enough to necessitate military-grade computing power. Certainly in archaeology, our understanding of past human and hominid behaviour is so limited by the partial nature of the record and the complexity of social-cultural systems that building highly specific or complicated models laden with untested assumptions is probably unnecessary, and may end up being counterproductive (Premo 2010). There is a growing chorus of researchers in archaeology and other fields who are arguing for an emphasis on models which have highly explicit assumptions, grounded in well-established first principles, and represent key dynamics as simply as possible but no simpler (Grimm et al. 2005, O’Sullivan et al. 2012, Crema 2014). Using simple models allows us to more fully explore parameter spaces, and simpler programming environments such as NetLogo are more than suited to this task, if not purposely designed for it.
Some people may give you a hard time about using NetLogo, but the substance behind those claims devolves into little more than CS snobbery. It’s true we’ll never h4ck the Gibson writing programs in NetLogo. But in the end, we’re social scientists, not software engineers. What matters ultimately is the quality of the models we build. All the computing power in the world won’t save you if you can’t think about social science problems in modelling terms, and thinking in modelling terms is aided by having tools that can build models closer to the speed of thinking. NetLogo is a low threshold, high ceiling platform: it’s easy to pick up, and its limitations are few (Tisue and Wilensky 2004). It allows for rapid prototyping, which has long been a major hurdle for using computer simulation in the social sciences (Lake 2010). If our goal is building simple, shareable models for communicating ideas and aiding in thinking about real-world problems, then NetLogo makes sense because it addresses those issues specifically.
References
Crema, Enrico R. “A Simulation Model of Fission–Fusion Dynamics and Long-Term Settlement Change.” Journal of Archaeological Method and Theory 21, no. 2 (2014): 385–404. doi:10.1007/s10816-013-9185-4.
Grimm, V, E. Revilla, U. Berger, F. Jeltsch, W. M. Mooij, S. F. Railsback, H.-H. Thulke, J. Weiner, T. Wiegand, and D. L. DeAngelis. “Pattern-Oriented Modeling of Agent-Based Complex Systems: Lessons from Ecology.” Science 310, no. 5750 (2005): 987–91. doi:10.1126/science.1116681.
Lake, M. W., 2010. “The uncertain future of simulating the past.” In Simulating change: archaeology into the twenty-first century, pp.12-20.Salt Lake City: University of Utah Press.
O’Sullivan, D., J.D.A. Millington, G.L.W. Perry, J. Wainwright (2012) Agent-based models – because they’re worth it? p.109 – 123 In: Heppenstall, A.J., A.T. Crooks, L.M. See, M. Batty (Eds.) Agent-Based Models of Geographical Systems, Springer. doi: 10.1007/978-90-481-8927-4_6
Premo, L. S. , 2010. “Equifinality and explanation: the role of agent-based modeling in postpositivist archaeology.” In Simulating change: archaeology into the twenty-first century, pp. 28-37. Salt Lake City: University of Utah Press.
Tisue, S., & Wilensky, U., 2004, NetLogo: Design and implementation of a multi-agent modeling environment, Paper presented at the Agent 2004 conference, Chicago, IL, October 2004.
Featured image: Screenshot from the Scale-color example in the NetLogo model library
What a nice well argued post! And how interesting that one can learn to predict the future by using the same what-if machine as archeologists. Thx.