Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

migrated from stackoverflow.com May 24 '11 at 11:47

This question came from our site for professional and enthusiast programmers.

4 Answers

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.

share|improve this answer
    
DSL - I already thought about embedding LUA or a similar language to read in configuration files. –  edgar.holleis May 25 '11 at 14:47
    
Blob - Interesting idea: You mean to (1) leave the defaults in the source code; then (2) auto-generate the configuration by "saving" or by scraping parameters from the source; (3) editing or merging the generated config-files and (4) load them back into the simulation. –  edgar.holleis May 25 '11 at 14:53
    
@edgar.holleis yes. not all data has to be extremely relationally structured to be useful. This struck me as a case where all you really need to do is edit the simulation parameters, then store and rehydrate them easily. –  Steven A. Lowe May 25 '11 at 15:27
add comment

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.

share|improve this answer
    
Do you mean embedding a language like LUA into the simulation framework? Or do you mean rewriting the simulation in an interpreted language? In how far would the latter help with parametrizing the simulation? –  edgar.holleis May 25 '11 at 14:41
    
@edgar.holleis: Yes. "rewriting the simulation in an interpreted language". "how far would the latter help..." Completely. 100%. A dynamic, interpreted language is it's own parameterization. Please follow a few tutorials for Python, Lisp, Smalltalk, whatever to see how your problem ceases to exist if you use an interpreted language. –  S.Lott May 25 '11 at 14:52
    
@S.Lott: You suggest making use of Code=Data and meta-programming to create a domain specific configuration language. That mostly solves the low-level stuff (parsing, instantiation). However it doesn't address the problem of how to structure and organize the data along with the code. Would you share any thoughts on that? –  edgar.holleis May 25 '11 at 15:30
    
@edgar.holleis: "You suggest making use of Code=Data and meta-programming". Not at all. Code==code. But interpreted code is more flexible than compiled code. You have many, many layers of code with varying degrees of configurability. "how to structure and organize the data"? There's nothing in the question about this; please open another question with some actual details. –  S.Lott May 25 '11 at 15:48
    
@S.Lott: "interpreted code is more flexible than compiled code": I fail to see your point. Do you mean dynamically typed language vs. statically typed language? What makes interpreted code more flexible? Especially in a scientific environment where it's perfectly fine to keep the compiler close. –  edgar.holleis May 25 '11 at 21:32
show 3 more comments

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.

share|improve this answer
    
Databases are almost certainly not the way to go. We need the parametrization close to the code. You see, almost all usage scenarios for agent-based simulation involve changing some of its code - like creating a new type of controller and test the resulting agent against agents using the old controller. So 90% of the users are in fact programmers. We use source-control, branching and merging and parametrization-data should live in source-control as well. –  edgar.holleis May 25 '11 at 15:04
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.