Guidelines for choosing a simulation/modeling (s/m) system

Navigation:  Geocomputational methods and modeling > Geosimulation >

Guidelines for choosing a simulation/modeling (s/m) system

Previous pageReturn to chapter overviewNext page

Ideally, a modeler would have comprehensive practical experience in a range of modeling/simulation (s/m) systems before choosing which system to use for a specific task. Unfortunately, this is not usually feasible. For this reason several authors (Najlis et al., 2001; Serenko and Detlor, 2002; Tobias and Hofmann, 2004; Rixon et al., 2005; Roberson, 2005; Dugdale, 2006) have surveyed a number of systems, identifying key criteria that should be considered before making a decision.

General criteria include, but are not limited to:

ease of developing the model/using the system
size of the community using the system
availability of help or support (most probably from the user community)
size of the community familiar with the programming language in which the system is implemented (if a programming language is necessary to implement the model)
is the system still maintained and/or updated?
availability of demonstration or template models
availability of technical details and ‘how-to’ documentation, etc.

Criteria relating specifically to a system’s modeling functionality include:

number of agents that can be modeled
degree of interaction between agents
ability to represent multiple organizational/hierarchical levels of agents
variety of model environments available (network, raster, and vector); possible topological relationship between agents
management of spatial relationships between agents, and agents with their environment
mechanisms for scheduling and sequencing events, etc.

These criteria will be weighted differently depending on a modeler’s personal preferences and abilities (e.g. the specification of the model to be developed, programming experience/knowledge, etc.)

Another important distinction separating s/m systems is their licensing policy: viz. whether they are open source, shareware/freeware, or proprietary. Open source s/m systems constitute toolkits or software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the system without paying royalties or fees. A key advantage of open source s/m systems relates to the transparency of their inner workings. The user can explore the source code, permitting the modification, extension and correction of the system if necessary. This is particularly useful for verifying a model (see Section 8.2.11, Verification and calibration of agent-based models). The predominant open source s/m systems are toolkits (e.g. MASON, Repast, SWARM, etc.).

The distinction between an open source s/m system and a shareware/freeware system is subtle. There is no single accepted definition of the term shareware/freeware, but the expression is commonly used to describe a system that can be redistributed but not modified, primarily because the source code is unavailable. Consequently, shareware/ freeware systems (e.g. StarLogo, NetLogo, OBEUS, etc.) do not have the same flexibility, extendability or potential for verification (access to their source code), as open source systems. Similarly, shareware/freeware systems tend to be toolkits, rather than software packages.

Finally, proprietary s/m systems are available for developing agent-based models. Proprietary systems are mainly software, developed by an organization who exercises control over its distribution and use; most require a license at a financial cost to the user. These systems have the advantage of being professionally designed and built for a specific use, and are often relatively simple to use. However, they often lack the community support found with open source or shareware/freeware systems. Moreover, since access to their source code is prohibited, a model developed with proprietary software is essentially black box. A modeler may therefore be left unsure about the inner validity of a model constructed with a proprietary system. This situation is compounded when the output of a model is emergent or unexpected.

Striking a balance between the aforementioned criteria is difficult. Unfortunately, while identifying a suitable system for the development of an agent-based model, too much time can often be expended trying to find this balance. This can be perceived as a trade off between the difficulty of developing a model (e.g. in terms of time required to program the model, understand how to develop a model with a specific system, or acquiring experience and knowledge of a programming language if required, etc.), versus the modeling power provided by the s/m system (e.g. modeling capabilities and functionality, as highlighted in Figure 8‑6).

Figure 8‑6 Model development balance

clip0399

The key is striking a ‘personal’ balance between these criteria. For example, those more accustomed to programming may prefer the functionality and flexibility of an s/m toolkit. However, modelers who only wish to develop a basic or prototype model quickly and easily, possibly with little or no programming skills, may prefer to use packaged s/m software.