TransmissionLab Update

Yesterday I posted TransmissionLab version 1.4, a fairly major reworking of the model class core. I was dissatisfied with the way that RepastJ models, by default, seemed to tightly couple the main model class to all of the other classes I’d written for data collection, transmission rules, and population construction. My goal with TransmissionLab is really a framework for building models to study cultural communication and transmission, not just writing one giant model and bolting new stuff on.

A paper by Railsbeck et al., in the September 2006 issue of Simulation, is right on the money in saying that the original Objective-C version of the Swarm toolkit is a strong “framework,” as opposed to the “library” style of successor toolkits like RepastJ and MASON. Swarm definitely forced a style of organization onto your simulation models, via the concept of nested “swarms” of agents, observers, etc. I suspect this is much like Ascape, but the latter doesn’t seem to be an active development project any longer (at least given the website – leave a comment if this incorrect). Whereas Repast provides a ton of infrastructure but simulation models themselves seem to be fairly unstructured, as I read various examples and models folks have posted online.

One of the reasons it’s hard to create a generic framework for computational models is that they differ in structure and needs across domains. On the other hand, within a specific research domain, it seems like structure should be relatively standardized, particularly if we want to communicate, share, and replicate results. So the governing philosophy I’ve been using with TransmissionLab is that of a domain-specific standard modeling framework built on a standard generic toolkit, tailored to the research needs of a given domain (in this case heritability/genetics/cultural transmission modeling), but flexible enough to allow the building of many models by different groups of researchers. We’ll see how this works out, but it seems like a good “middle” approach to the problem.

Version 1.4 of TransmissionLab is a reasonable step in that direction. Nearly all of the “boilerplate” involved in building a computational model is abstracted into a series of Java interfaces and abstract classes (which provide templated partial implementations for the interfaces). All of the “machinery” of the simulation deal exclusively with interfaces, such that nearly anything that the “user” writes can be considered a reusable component. For example, in the rules package, TransmissionLab currently includes a rule for “mutation” called RandomAgentInfiniteAllelesMutation. Assuming that “traits” are being represented as integer “tags” (a generalization of this will be in a future version to allow Object traits with internal structure), this rule will operate on any implementing class of the interface IAgentPopulation. This allows a simulation author to reuse this mutation rule, creating populations that are well-mixed, spatially structured, network-structured, and so on.

The central model class (which contains the “main” method, for example) is similarly templated. The “component” classes (rules, data collectors, population factories) all work with classes which implement ISimulationModel. In practice, main model classes extend the abstract class AbstractTLModel, which provides full or partial (template method pattern) implementations of the ISimulationModel interface contract. By design, satisfying the ISimulationModel contract also guarantees that your model class meets the needs of the SimModel contract in Repast, and thus will be runnable by any standard Repast method. But since much of this “infrastructure” is contained in the abstract base class, user-written model classes are much much simpler. In fact, looking at the new implementation of the Random Copying Model this morning (class NeutralCTModel), it strikes me that everything in it could be specified declaratively, in an XML configuration file. So I may get to the point soon where user-written models are just XML files, users write new components as Java classes, and the framework stitches together the rest.

All of this may sound suspiciously like Repast Simphony, so why I am putting in this work?

Several reasons. Simphony is still alpha code, and although it’s coming along very nicely, I’m not yet sure what I think of it as a modeling framework. Clearly many of the goals are the same as I’m discussing here, and I may port TransmissionLab to Simphony down the road.

But Simphony is a bit of a “black box” at the moment: I’m not quite sure how it all works under the hood, and that bothers me. Exploratory simulations are fine if I don’t understand the fine detail of the runtime, but if we’re going to be sure that we’re getting scientifically usable results out of a computational model, we’d better darned well know exactly how the model works, period. This is the problem I have with NetLogo (other than proprietariness and the fact that it’s well suited to specific types of models, not generic simulation).

So I’m still working with RepastJ, and plan to continue doing so until there’s a compelling case to switch. And working with RepastJ is a lot simpler if you have just a bit more structure. So TransmissionLab will continue to evolve in the direction of a domain-specific modeling framework using RepastJ. If you’re doing simulations of cultural communication and transmission phenomena, check it out.