Notes on Simulator Design PhilosophyNotes on Simulator Design Philosophy
There are in general two sorts of evolutionary computer models. Population models and agent-based models (which include cellular automata). Population models tend to abstract away from individuals, focusing instead on the "economics" of the way population indices change. Population models are thus very good at identifying matters of principle that are of theoretical interest. Agent-based models (also-called "individual-based models") explicitly represent each member of the population, and makeit possible to incorporate spatial locations and a variety of complex behaviors. Agent-based models on our view make good tools of exploration, where complex systems can be built and explored and unexpected relationships discovered. They suffer, however, from the "curse of complexity". They tend to have lots of free variables, so that it is often difficult to discover the cause of the unexpected phenomenon one has discovered.
On our conception, population modeling and agent-based modeling play complementary roles in a fully developed methodology. Agent based models serve as a place to experiment and discover new relationships. Population models serve as a place to develop explanations for those relationships. The relationship is like that between lab and theoretical science. Good population models (like good theory) predict the behavior of agent-based models. The behavior of agent-based models suggest directions for the future develoment of the more abstract population models. Rather than devoting oneself to one or the other, we must become facile with both.
Our approach then is to try and develop general tools for doing both population and agent-based modeling. We choose Java Applets because this allows models to be shared over the web, quickly, anywhere in the world (that has web access).
The First Generation: Originally, we had thought to exploit the object-oriented nature of Java to provide a modeling class library to client programmers. Object oriented programming packages code into convenient reusable modules called "objects". We reasoned that development time for modelers could be significantly reduced by providing a library of pre-defined objects like agents, patches (locations with resources), environments (which hold agents and patches), and interfaces. So the first generation EAME agent-and-patch simulator package consists of about nine source files which define ancestor and descendant classes for agent, patch, and environment, and a number of interface classes. Resource transfer methods were protected in the ancestor classes which served to enforce rules of resource transfer, movement, and so forth. (I.e., the idea was to limit what the client programmer, the user of the classes, could modify.)
The resulting package had two major defects. The first is somwhat specific to the downloadable mission of Java applets - the programs were large and somewhat unwieldy. In addition to multiple class files, enthusiasm for a flexible interface had led to the incorporation of several non-standard GUI components (the symantec spin buttons and tab panels) which added to the download time and seem to slow down execution. This problem was somewhat obviated by the use of JAR files (a sort of Java zip file which allows all classes to be downloaded from a single server hit), but the size and execution problem remained.
More serious was that, as we attempted to put the package to use, we found ourselves consistently wanting to modify numerous aspects of the source code of the various modules. Having written the package, this was not too difficult, but it made clear that the approach we had taken would make the kinds of modifications that client programmers needed to do exceedingly awkward. Moreover, unlike the typical scenario where builders of class libraries "hide the implementation" from client programmers, modelers need to know excactly how everything works, and the very activity of modeling consists largely of modifications of various aspects of the implementation. In short, our attempt to conform to standard object oriented paradigm for software development led to a package which, however powerful, would do little to reduce development time for other modelers.
The Second Generation: We realized that what we needed to do was to try and capture the functionality of the agent-patch package in a way that would make it as easy as possible for other modelers to
To this end, the agent-patch package was rewritten from the ground up. The idea was to optimize the source code for readability and compactness, to reduce the number of classes involved and the number of source files required for compilation. The second generation agent-patch simulator consequently consists in just one Java source file (all necessary non-standard classes are defined therein), which makes it much easier to see how everything was done.
We also realized that, while, Java applets maximize the security for those who download them (applets run within a "virtual machine" and cannot access files or start other programs) this made the record keeping essential to actually doing research with simulators somewhat awkward. Consequently, the most recent versions include a "wrapper" class which allows the applets to be run as java "application", which can then store records of the simulation on the local machine. Details are included in the documentation for the specific package.