Linking Repast to another Java program

Repast is one of the leading software packages for agent-based simulation. It provides useful classes for building and controlling simulations and users can run their models using a graphic display or in batch mode. These functions are fairly straight-forward if you want to build a stand-alone Repast simulation but what if you want to integrate Repast within a larger modelling system? This tutorial will explain the problem and show a solution influenced by design patterns.

Let’s assume that we have a programme that implements a number of different models. Each model extends an AbstractModel class, which uses the Template pattern to enforce a particular run order (e.g. setup(), execute(), report()). We want to create a Repast ABM that extends this class; however to take advantage of Repast’s facilities we would also like to extend the SimModelImpl class and our new MyABM class can’t have two super-classes.

So what can we do? One solution would be to extend the AbstractModel class and implement Repast’s SimModel interface. This would ensure that all the functionality is there but we would have to manually rewrite the implementations of the interface methods; this is both time-consuming and dangerous – you could have collisions between the names of the interface methods and the AbstractModel methods and if Repast’s code changes, you have to make sure that your implementing methods are consistent with the new code. Not ideal.

The solution is to separate the functionality of the MyABM class into two classes. In the first class, MyABM, we build our agent-based model as if it were a regular Repast ABM by extending the SimModelImpl class. We can even add a main(args[]) method so that it can be run on its own. We then create a second class, MyABMController, which extends AbstractModel. This class implements the template methods needed to actually run the model. The key to this structure is that both MyABM and MyABMController contain a reference to one another. The class diagram is something like this:

In the code example below, I will assume that MyABM will be run as a batch model (i.e. no GUI). Remember that the AbstractModel class requires subclasses to implement an execute() method; the relevant code in MyABMController to call our ABM is therefore:

public void execute() {
 SimInit init = new SimInit();
 MyABM model = new MyABM(this);
 init.loadModel(model, "params.txt", true);
}


Note that the constructor for the model requires a reference back to the controller. This is then used by MyABM to retrieve data from the rest of the model, e.g. when initialise agents and spaces or other data.

If you run this code, you’ll notice a problem though. Because our simulation is running as a batch model, the user can’t press a button to make the run stop. This needs to be explicitly scheduled in MyABM‘s buildSchedule method (see this tutorial for more information). While a simple call to the inherited stop() method will stop the model, it also stops the entire Java VM including our calling environment. Therefore we need to add an extra line telling the IController not to stop everything when the model finishes. The scheduling code block is something like this, with nTicks representing the desired number of ticks before the model stops.

class StopModel extends BasicAction {
 public void execute(){
  // ensure that Java stays running
  getController().setExitOnExit(false);
  // stop the model
  stop();
 }
}
int nTicks = 1000;
schedule.scheduleActionAt(nTicks, new StopModel(), Schedule.LAST);

You’ll now be returned to your original calling environment in MyABMController.

public void execute() {
 SimInit init = new SimInit();
 MyABM model = new MyABM(this);
 init.loadModel(model, "params.txt", true);

 // Back from Repast!
 System.out.println("Welcome back!");
}


I’m not sure if this solution is actually an example of a design pattern but it does apply some of the same principles. It works though and that’s the main thing!