Parameterize Agent Based Simulation (OOP-Question)

Question

I'd like to hear my fellow programmer's thoughts on the issue of parametrizing agent based simulations:

Consider:

• Simulation core, including geometry, collision tests, some rules
• Different agents (modelled in OOP-fashion: has-a, is-a, abstract interfaces)
• Agents have different sensors, different actors, different controllers, ... All connected together by references/pointers and accessed using abstract interfaces.

So essentially, each agent is composed of an ownership tree (agent owns sensors, controller, actors), superimposed by a dataflow-graph (sensor connected to controller, connected to actor). The tree, the graph plus the parametrization of the things together form a simulation setup. Running a simulation amounts to:

• Read in simulation setup
• Instantiate a bunch of objects, parametrize and connect them together to form the tree and the graph
• Run simulation
• Output some data (statistics, signals, whatever)

The question is how best to save the simulation setup, and how to instantiate & parametrize stuff.

Requirements (some of them conflicting):

1. The parametrization should probably be structured along the ownership tree, as it feels most natural.
2. A lot of times I'd like to instantiate a bunch of similar agents with just the 1 or 2 parameters changed between instances. That needs to be easy.
3. I'd like to keep parametrization and code close together. When experimenting with algorithms that are affected by parametrization, I wouldn't want the changes to be spread out over too many places.
4. Conversely, I'd like to keep parametrization out of the code, so that it's easy to automate simulation runs in order to systematically sweep through parameter spaces.
5. Parameters have meta-data: type, value range, physical unit, textual description, logical dependencies (e.g. if you specify X you must not specify Y)
6. Parameters not only affect data (member variables) but also code (usage of a particular specialization of the abstract base)

---

Now my colleges and me are tasked with building a new agent-based simulation:

• Do you know any frameworks / libraries / techniques?
• Are any patterns applicable? Best practises?
• Meta-programming?
• Abandon OOP altogether?

Looking forward to your thoughts.

Answer 1

DSL

Reconsider the domain-specific language approach. From your description that sounds most appropriate. It is a lot of work, but if this is going to be a long-lived simulation system the effort may be worthwhile.

Blob

If this is not going to be a long-lived system, consider just dumping parameters into JSON (or XML, or name-value pairs, et al) blobs in a database keyed by agent type and scenario name. Simple serialization, in other words. Write a scenario editor to maintain the data. I'm guessing here that the results of the simulation are far more important than the beauty of the simulation code, as long as it does what you need it to without excess hassle/tedium.

Answer 2

Do you know any frameworks / libraries / techniques?

Find a better language. Compiling doesn't help. Repeating yourself in XML doesn't help. Writing a DSL doesn't help.

Use an interpreted language. Python, Smalltalk, Lisp leap to mind.

Are any patterns applicable? Best practises?

Yes. Use an intepreted language.

Meta-programming?

Avoid this.

Abandon OOP altogether?

OOP was invented expressly for this purpose. Read the history of Simula and related languages.

If you can't do simulation in OOP, something very bad is happening around the edges of the project and leading you astray.

Answer 3

I see how xml parsing can get painful, but have you thought about document models? (JSON based for example).

If you are going down this path, there are databases that are document based (couchDB) which can help in storing/querying this data. And with decent normalization of your data, you could build a system with following components: 1. Manages data storage / parsing / analysis / reporting 2. A component that handles generating simulation samples from this data. (For example, you might want all data that are permutations of X:Y)

The biggest problem I have seen in configuration oriented systems is that sooner or later people start losing out on separation of concerns / SRP. This way, data gets messy and so on. Once you build a data management system, these difficulties should reduce.

Also, at a team level you should come to an understanding that this is something that is very necessary. The other end of this is unlimited number of C files that are hard to maintain/edit etc. Data in code has usually resulted in trouble.

Answer 4

How you parameterize is tightly linked to how your overall simulation is designed.

One approach that I have used in this situation goes something like this.

The components you model should all derive from some common class that your simulation engine can deal with. These include methods for simulation (event handling and timing), and communication (message passing).

The simulation engine is responsible for timing and event management, and also for message passing.

The class interface should have a standard set of methods so that elements can be connected together. All interactions between your model elements should go through the standard communication methods.

A simulation engine that I have successfully used is DEVS-Suite.