Page 80 -

5 Informal Approaches to Developing Simulation Models 75

simply continue to use the same system as they have used on previous projects,
without considering alternatives. There is no simple answer as to which system
is the “best”. The available options are constantly changing as new systems are
developed and old ones stop being supported. The type of modelling problem will
influence the decision. And indeed it is partly a personal decision, depending on
the modeller’s own personal style and preferences. However, given that such an
investment is involved in learning a new system, it is a good idea to make this
investment in one that will have large payoffs and that will be useful for developing
a wide range of models.
Systems for developing and testing simulations range from the very specific to
those that claim to be fairly generally applicable. At the specific end, there are
simulators that are designed with a restricted target in mind—such as a grid-based
6
simulation of land use change (e.g. FEARLUS, Polhill et al. 2001, or SLUDGE,
Parker and Meretsky 2004)—where most of the structures, algorithms and outputs
are already built in. The user has some latitude to adapt the simulation for their
own modelling ends, but the ease with which one can make small changes and
quickly get some results may be at the cost of being stuck with inbuilt modelling
assumptions, which may not be appropriate for the task at hand. The specificity of
the model means that it is not easy to adapt the system beyond a certain point; it
is not a universal system, capable, in principle, of being adapted to any modelling
goal. Thus, such a specific modelling framework allows ease of use at the cost of a
lack of flexibility.
At the other end of the spectrum are systems that aim to be general systems
to support simulation work that can, at least in principle, allow you to build any
simulation that can be conceived. Such systems will usually be close to a computer
programming language and usually include a host of libraries and facilities for
the modeller to use. The difficulty with this type of system is that it can take
considerable effort to learn to use it. The range of features, tools and libraries that
they provide take time to learn and understand, as does learning the best ways to
combine these features. Furthermore, even if a system in principle makes it possible
to implement a modelling goal, different systems have different strengths and
weaknesses, making any particular system better for some types of models and less
good for others. Thus, modellers will sometimes “fight the system”, implementing
workarounds so that their model can be implemented within the system in which
they have invested so much time, when in fact the model could more efficiently be
implemented in an alternative system.
Between these two extremes lie a host of intermediate systems. Because they are
often open source, and indeed more specific modelling frameworks are commonly
built within one of these generic systems, it is usually possible (given enough time
and skill) to “dig down” to the underlying system and change most aspects of these
systems. However, the fundamental trade-offs remain—the more of a simulation
that is “given”, the more difficult it will be to adapt and the more likely it is that
assumptions that are not fully understood will affect results.

6 http://www.macaulay.ac.uk/fearlus/