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!

I’m working on the conclusion chapter of my thesis at the moment. It’s meant to sum up the results presented in earlier chapters and then discuss wider questions in the literature and for policy. There are a couple ideas I’m working on, such as an ideal tariff for microgenerators and clarifying PV’s place within the context of other household energy conservation measures, but a basic concern is sorting out how PV households interact with other stakeholders within the PV industry.

I wasn’t really sure how to start answering this question until a friend told me about Pajek. It’s a bit of software that can be used to analyse large social networks and it will perform all sorts of calculations. The options can be a bit confusing though so I thought I’d start simple. I entered some data from my interviews and you can see the resulting plot below. The size of the dots represents the ability of each node to control the network (inverse of dyadic constraint if you’re interested).

This is only a first draft but reassuringly, some basic things like a strong connection between PV households, electricity suppliers and PV installers can be seen. It also seems to show that the DTI and Ofgem play a major role behind the scenes, framing the interactions of other stakeholders. This came out of the interviews as well but the advantage of the network graph is that it’s immediately clear that there is no direct link between households and these government agencies. So, for example, if we want PV households to become more active participants in the electricity network – i.e. exporting electricity at times when it’s good for the grid or generally reducing demand – then the graph suggests that perhaps a link between DTI, Ofgem and the households needs to be built. This might be achieved by developing a pilot programme with innovative metering and monitoring technologies, working in conjunction with the electricity suppliers and PV installers. As it happens, there has actually been talk of doing just that!

That’s a pretty rough sketch of course but I’m keen to play with Pajek a bit more and see what I else I might be able to find out.

As I was saying last time, I’ve got quite a bit of configuration data used in the model and I couldn’t figure out a good way to access it quickly and without too much coding. After the EnumMap stuff (which works fine but gets a bit cumbersome if you try and do anything to fancy), I switched to a JDBC connection to Access. Again it works fine but because of how frequently the database needs to be checked, it ends up being really slow.

So I was poking around on the web trying to find a solution and came across HSQLDB. Bit of a mouthful I know, but it really is a fantastic solution to this problem. Why? Because it lets you create an SQL style internal database. That’s right – at the start of my model I load everything in from the Access database, make a copy of it in RAM using HSQLDB, and then use that copy for the rest of the model run. It’s really fast but any changes to the database are lost when the model finishes. At the moment that’s fine but I may add something to periodically write to file.

That’s another sub-version done. Things are coming along quite nicely.

I’m making good progress on the next version of the model, adding more configuration information for the initialization of household agents. However I’m having difficulty deciding on a common file format so that I can have just one or two methods for reading in files and parsing them into appropriate input. Some of my files have two or three columns, some labelled rows, some just single numeric values. In some ways it would be easier if everything was in a database but I kind of like using text files since it’s very easy to see what’s going on, add comments and share information – everyone’s got Notepad but not everyone has the latest MySQL setup.

But once the data’s in from the file I’ve got another problem about how to store it. At the moment, I’ve defined many of my finite data categories as enum types. For example, households can either be FAMILY or RETIRED. This works great in some respects: I can use the fast EnumMap to store data and it makes iterating very easy. Of course, enum’s are final static so if I want to expand the range of enum types I need to edit the source. Adding extra types also has implications for the text file inputs – again it might be easier if everything was done with databases since I could just add fields and so on as new data types are added.

Any thoughts on how might be the best way to manipulate this type of data? Am I going to have to bite the bullet and move away from text files?

Last week I finished the first version of my model and I’m pretty pleased with how it works so far.

There are twp issues worth noting though. JUnit was and is invaluable in developing the model but since my model uses a lot of random numbers it can be tricky to write the assert cases since you don’t know what the outcome of a particular method might be. To get around this, I’ve created dummy input files with binary (0 or 1) input data. Ordinarily these values would be a probability between 0 and 1 but with the test input, I know definitely what the model is doing at any stage.

The other one is that the model outputs its results to a text file as it goes along. This makes it kind of tricky to write a JUnit test. Perhaps there is some way of doing this but for the moment I just output everything to a file and look at it manually to see if the data makes sense.

PS In case anyone’s wondering about the version numbers. V0.1 was a dummy version, just playing around with Repast and Eclipse. V0.2 was a more serious attempt and had a few interesting features liking reading in input from a proper database (well Access…). I’ve tried to map out the version numbers so that they’ll make some sense, at least in hindsight. For the moment I’m planning on adding features to the basic model for the 0.3x releases. I think V0.4 will introduce the all of the remaining agents, though they may not be fully implemented.

I’ve been trying to figure out how to model load profiles for different appliances. There are a few different approaches but the most sensible approach begins by assuming that, for an appliance to be used:

• the household needs to be occupied (i.e. somebody’s home)
• the household occupant wants to use the appliance (a desired activity)
• the activity requires a certain appliance

There are some different ways to allocate the precise timing but I think I’m going to simplify this approach. I’ll test it and then if that doesn’t work I’ll try something different.

I just came across CodeZoo, which is a recently launched site with free libraries for a whole bunch of standard tasks. It looks like it should be really useful – just a quick browse brings up all sorts of things that I might want to use.

I came across another interesting article on simulating load profiles and this one suggests using principal components analysis and some regression. I had a go with it yesterday and managed to get a pretty good approximation using one year of electricity demand data at hourly interval. Running princomp in R, I picked three components out of 24 and that covers 98% of the variance. Check it out (click for bigger):

The next step is to add some exogenous variables and see if I can generate new curves given likely temperatures, days of the week, holidays and so on. I’ll have to brush up on my matrix math a bit first though.

I ordered a copy of Java in a Nutshell a couple months ago and it finally arrived today. It looks pretty good but as my office mates pointed out, what size nutshell are they referring to? The thing weighs in at over 1200 pages!

I recently submitted a paper which said that an integrated model of domestic energy consumption is desperately needed. What’s more, I said that it didn’t look as though anyone else was really working on something like this. Turns out I was only partly right – people are working on integrated models, they’re just not integrating them with each other.

The idea of the paper was that if people could get behind one way of discussing domestic energy consumption, refering to its different constituent parts, and exploring the links between these parts, energy researchers would be better off. Research from one discipline could be used in another by using such a framework to put things in context. People would be speaking the same language and even if things weren’t perfect, it would be a big step forward.

These other projects that I’ve recently come across (CARB and Tyndall’s CIAM) seem to be going down the same path but in different directions. Both are trying to integrate the complexities of energy consumption (not just in the domestic sector) but they seem to be struggling to find this sort of common language. To be fair, both projects have slightly different aims and they have only begun recently and perhaps they’ve tried to find a common language and decided against it.

I realize that might come across wrong so let me clarify the two points I’m trying to make:

1. It’s great that other people are trying to develop an integrated model of energy consumption. Funny that everyone seems to be getting the same idea all at once but the more the merrier I see and hopefully something will come of it.
2. However given all the effort that has been and will be invested in these two projects, some effort should be made to reduce overlap and present them in a compatible way. I don’t think multiple “integrated” models are terribly useful by definition – there should at least be some degree of theoretical compatibility between integrated models.

This doesn’t mean that what I’m working on is an ideal third way. These other projects, like my work, is just starting and so I’m very keen to see how they progress. Given my flexibility as a doctoral student, I hope that I will be able to learn from these two projects, build a theoretical foundation and present a model which I feel is suitable for the integrated analysis of energy consumption.