It should be noted that there are hundreds and maybe thousands of software packages that can be related to modeling. By no means we can overview even a small fraction of them. Our goal was to look at some representative examples and try to put them in some order. Clearly, for starters, especially with no or little quantitative and programming skills, it makes more sense to start at the bottom of the spectrum and explore some of the existing models or modeling systems. They will take care ofmuch ofthe tedious model organization, make sure that the model is consistent, may help with unit conversions, logic of computations, and will immediately offer some numeric methods to run your simulation. As tasks become more complex, you will most likely need to move higher up the diagram in Figure 1, and explore some of the more sophisticated modeling tools and methods.
Most of the software tools are living organisms, which usually go through life stages: after they are born, they develop, reach maturity, and then sometimes decline and die. It is hard to predict what will be the future of many of these products, especially when they are corporately owned and depend upon the dynamics of world markets. In this regard, well-developed open source products promise more continuity, but even they can fade away, or get replaced with something better. Apparently this is what we see now with Swarm, which tends to morph into other products, such as Repast. Similarly, SME has been hardly developing over the past few years. In the proprietary world, there does not seem to be much progress in the ModelMaker development. Similarly, Stella seems to be mostly relying on its previous success and does not show much improvement over the past several years. The bottom line is that we need to keep a close look at all these systems and be flexible enough to migrate from one to another. The 'hammer-nail' syndrome should be avoided by all means. No modeling software is universal. There are always systems that could be better modeled using a different formalism and different mathematics and software. If you confine yourself to only one modeling system, you may start to think that modeling is only what the software offers you. In reality, there are numerous different approaches, and all of them may be worth considering when deciding how to model the system of interest.
Models built using open source software are most desirable, since they can be modified to meet particular needs of various applications. Besides they can be tested and fixed if errors are found. While commercial proprietary software comes as closed 'black' boxes, whose inside one can never be sure about, open source models are open, and the source code can be viewed and modified. On the other hand, commercial products tend to be better documented and supported. One rule of thumb is that if a project has much brainpower and enthusiasm - go for open source. If there is good funding in the project - go for commercial products.
Modeling is iterative and interactive. The goal oftentimes gets modified while the project evolves. It is much more a process than a product. It becomes harder to agree on the desired outcomes and the features of the product. This certainly does not help when choosing the right software package to support modeling efforts. There is also a big difference between software development and modeling, and software engineers and modelers may have different attitudes about software development. For a software engineer, the exponential growth of computer performance offers unlimited resources for the development of new modeling systems. Models are viewed by engineers as just pieces of software that can be built from blocks or objects, almost automatically and then connected, perhaps even over the web, and distributed over a network of computers. It is simply a matter of choosing the right architecture and writing the appropriate code. The code is either correct or not, either it works or crashes. Not so with a research model. Instead, scientists would say that a model is useful only as an eloquent simplification of reality and needs profound understanding of the system to be built. A model should tell us more about the system, than simply the data available. Even the best model can be wrong and yet quite useful if it enhances our understanding of the system. Moreover, it often takes a long time to develop and test a scientific model.
As a result of this difference in point of view and approach, we tend to see much more rapid development of new languages, software development tools and code, and information-sharing approaches among software engineers. In some cases, new software packages appear faster than their user community develops. In contrast, we see relatively slow adoption of these tools and approaches by the research modeling community. The proliferation of modeling software, like in case of systems dynamics modeling tools, may be even considered as an impediment since if there were only one or two modeling tools generally accepted by all, they could be used as a common modeling platform, as a communication tool to share and distribute models. With so many different clones of the same basic approach, we get a whole variety of dialects, using which it may be harder to find common ground.
See also: Ecological Models, Optimization; IndividualBased Models; Modules in Modeling; Numerical Methods for Local Models; Participatory Modeling; Visualization and Interaction Design for Ecosystem Modeling.
Was this article helpful?