Glossary of Terms
Chapter 4: Methodology
4.8 Agent Based Modelling
139
• Limited scope of the social networks of people asked to nominate participants into the other Local stakeholder group’s sub-categories; and
• Reliance on the computer literacy and Internet access of the participants.
There were twenty-two participants within the Expert panel with representatives from each of the sub-categories so the Expert panel is in fact rather diverse. There were a total of fifteen participants in the Funding agency panel, with at least one participant from each of the sub- categories except for from a Volunteer organisation.
Once a number of potential participants had been identified, they were invited into the process.
This was done via phone conversations and by sending a document describing the background and aim of the study, time requirements and scope, as well as the expected outcomes in realistic terms. Most of the invited participants agreed to take part in the dialogue.
140 With the decision to apply ABM in this study, there is a need to specify our ABM further, in particular regarding the Modelling requirements; Design process; Software development environment; and Model structure.
4.8.1 Modelling requirements
I have deemed that the following requirements, based on the ABM taxonomy by Hare and Deadman (2004) are appropriate in this study:
• Space is represented in an explicit way, albeit without accurate representation. This is because it is believed that the particular spatial setup is not a critical influence on the behaviour of the system other than in a very general sense;
• Heuristic rules and imitation are used to model individual decision making. This is due to a combination of difficulty in accurately modelling rational and boundedly rational behaviour using utility functions and inferences without significant understanding of the local culture.
Heuristics and imitation can incorporate insights from social psychology.
• Social interaction is through a combination of group based tasks, and a combination of local as well as global social adaptation. This is chosen because it is perceived that for the urban water system, individuals are interacting essentially anonymously to a group based task;
whilst individual households do tend to adjust their behaviour and mental models in response to what they can observe in neighbours and elsewhere.
4.8.2 Design process
The design process for the ABM is inherently coupled with the Interviews and the Historical review. The mediating objects that are used to facilitate the design process and the interactions with the Interviews are Unified Modelling Diagrams. This coupling between ABM design and Semi-structured interviews is as follows (as in Figure 4-7): knowledge gained and information collected in the interviews is used to develop UML diagrams and populate the model; UML diagrams are in turn used in semi-structured interviews as part of the interviews; and finally, UML diagrams are used in semi-structured interviews for stakeholder evaluation of models.
141 Figure 4-7: Information flows from survey to model
Therefore, in line with the Participatory Modelling philosophy that has been adopted, the ABM is viewed as socially constructed based on input from stakeholders. UML diagrams are seen as the stepping stones that can facilitate this transaction.
4.8.3 Software Environment
ABM relies on the Object Oriented Programming paradigm. Whilst ABMs in theory can be programmed in any object-oriented programming language such as Visual Basic, C#, Python or Java, as described by Rixon and colleagues (2005) there are also a number of Integrated Development Environments availableas summarised by SwarmWiki (2009). Notable examples of these are shown in Table 4-4. There are obviously also other ABM Integrated Development Environments, but these appear to be the most commonly used within contexts similar to this study.
The requirements for an ABM Integrated Development Environment when undertaking Participatory Modelling is that it:
• Supports rapid development; allowing for quick turnaround when adapting models to user and stakeholder feedback;
142
• Is free and Open Source; allowing for handing over ownership of models; and
• Has excellent visualisation features; allowing for efficient communication.
Using these three evaluation criteria, DIAS/FACET, NetLogo, and Jack are no longer viable options because at the time of choosing, they were not free and open source. RePast, MadKit and Swarm on the other hand do not adequately support rapid development unless the research team is of sufficient size and with sufficient programming skills. This leaves one remaining option, Cormas which is selected because of the list of characteristics shown in Table 4-5.
Table 4-4: Selected ABM integrated development environments
IDE Reference Programming language Free and Open source
Cormas CIRAD 2004 Smalltalk Yes
Dias/Facet/JeoViewer Argonne National Laboratory 2004
Java No
Jack AOS Group 2004 Subset of Java No
MadKit MT 2004 Java, Python and Scheme Yes
NetLogo NetLogo 2009 Java Free but not open
RePast Repast 2009 Java, .NET, Python Yes
Swarm SwarmWiki 2009 Java, Objective C Yes
Notes: It is noted that this table was set up at the time that the decision had to be made and that some of
assessment results may have subsequently changed. However, this table does represent the information at the time the decision had to be made and is therefore consistent with the logic of choosing Cormas as an IDE. A more recent review of Agent Based Modelling platforms has been done by Railsback et al. (2006).
143 Table 4-5: Evaluation of Cormas as an integrated development environment
Criteria Evaluation of Cormas
Opportunities for code reuse Considerable due to the available models on the web site, and the existing AtollScape model for Tarawa.
Spatial representation Cormas provides capability to both use cells and cellular automatons (CA); and it also allows for reading in files containing cell/CA attributes (i.e. spatial layers).
Visualisation There is excellent support for defining and dynamically visualise probes and spatial layers.
Debugging capabilities Cormas has an efficient system for reporting errors, and debugging, albeit requiring some knowledge of features, and this knowledge is relatively poorly documented.
Suitability for prototyping and rapid development
With a large library of features, and an easy to use interface, Cormas is particularly suitable for rapid development. This is partly because memory handling, pointers and other technicalities are hidden, putting the focus on the actual models, and reducing the occurrence of bugs.
Effort required for development Relatively little effort required. The user has to specify the agent and model actions in each step, and the initialisation; and any method out of the ordinary has to be written using the Smalltalk programming language.
Learning required Requires some teaching and practice, and Cormas is not perfectly straightforward to learn. While extensive tutorials and users guides are available for the associated scripting language Smalltalk, there is currently limited written material for the Cormas platform itself.
Software scalability Because of the high level languages used, and the extensive support, Cormas is excellent for small to medium size developments, but other IDEs, such as RePast in particular, are more suitable for large scale developments.
User groups and support A users’ forum is available for questions and answers concerning the use of Cormas.
Notes: Again, it is noted that this is the evaluation of Cormas at the time that the decision had to be made; and that
there may have been subsequent changes. A more recent review of Agent Based Modelling platforms has been done by Railsback et al. (2006).
4.8.4 Model structure
The ABM model is structured in a manner which is typical for Cormas, containing:
• Model class containing
• A Scheduler implemented within the Model class as a method: step
• Alternative schedulers are implemented as different step methods
• An Initiation procedure implemented within the Model class as a method: init
• Alternative initiation procedures are implemented as different methods
144
• Probes implemented as methods, monitoring variables or functions of variables and can be displayed as dynamic graphs
• Spatial environment established by defining the cell class and relevant aggregates
• Social classes: in this case Landowners, Customers, Water utility, etc
• Passive classes, such as Weather and Pipe infrastructure, and Tariff structures.
Figure 4-8 describes how these components are embedded within the Model class.
Figure 4-9 shows how, within Cormas, a probe can be selected one at a time, by selection in the left part of the screen. The right part of the screen shows the chosen variable as they change with each time step. An ABM can be described in terms of its structure and components, i.e. its classes and interactions between classes; its dynamical properties; i.e. the sequence of events in each time step; and its spatial representation; i.e. the landscape in which the agents interact.
These perspectives of the model are described using Unified Modelling Language (UML) diagrams which are further described in the Results section (chapter7).
Model Class
Spatial elements Scheduler Initiation Probes Social classes Passiveclasses
Figure 4-8: General description of a typical Cormas ABM model structure
145 Figure 4-9: Illustration of how probes are displayed in the Cormas software