Main Page | Recent changes | View source | Page history

Printable version | All content dual-licensed under the GNU FDL and the Creative Commons Share-alike Attribution license. | Privacy policy | Latest revision

Not logged in
Log in | Help
 

Examples of Swarm applications

Revision as of 18:29, 9 February 2006 by SFRailsback (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Wiki main page
Swarm main page
Software main page
Stable release
Development snapshot
License
Platforms
Prior releases
Documentation main page
Doc set & reference guide
User guide
FAQ
User support email list
Applications & contrib code
Applications
User-contributed code
Release Management
Checklist
Swarm-logo.jpg

As we implement and debug Swarm we write sample applications to test our ideas and our software. These applications also make good demos of Swarm, as they tend to show off the best features of our tool. We've written up a few of our demos as Web pages. The images you see here are actual snapshots from running Swarm demonstrations, they were being produced on the fly while the system ran.

Heatbugs

Heatbugs is one of our canonical Swarm demonstrations, an example of how simple agents acting only on local information can produce complex global behaviour. It's simply a toy, but a nice demonstration of the concepts Swarm is about.

Figure 1. The Heatbug world

Each agent in this model is a heatbug. The world has a spatial property, heat, which diffuses and evaporates over time. In this picture, green dots represent heatbugs, brighter red represents warmer spots of the world.

Each heatbug puts out a small amount of heat, and also has a certain ideal temperature it wants to be. The system itself is a simple time stepped model: each time step, the heatbug looks moves to a nearby spot that will make it happier and then puts out a bit of heat. One heatbug by itself can't be warm enough, so over time they tend to cluster together for warmth.

You can think of the heatbugs system as an optimization problem: each heatbug is trying to minimize its unhappiness. The graph above demonstrates how well, over time, the average unhappiness of all bugs is being optimized. In this system, even though each bug is acting purely selfishly the average unhappiness over time is decreasing.

Figure 2. Data from the system

This graph represents only one small part of Swarm data collection, a simple (hardcoded) time-series graph. The Swarm system supports a variety of generic methods for tapping data from components of the system, combining those data through statistical filters, and displaying then with generic visualization objects or saving them to files. Much of this support is still under development, and so is not shown here.

Figure 3. Controlling the system

Part of the reason we build simulations is we can go in, tweak a few parameters, and see how the change affects things. The two windows shown above are a snapshot of some of the control features of Swarm: a form for user input of parameters, and a control panel to start and stop the simulation. Swarm models can also be configured and driven via the Lisp scripting language.

Mousetrap

An old grade school demonstration of nuclear fission. Lay a bunch of mousetraps on the floor in a regular grid, and load each mousetrap with two ping pong balls. Drop one ping pong ball in the middle and watch the fun begin! (Unfortunately, Swarm does not yet support sound.)

We implemented this in Swarm as an example of a simple discrete event simulation. Time stepping each mousetrap would be incredibly inefficient, since most mousetraps are doing nothing most of the time. Instead, we simulate each ping-pong ball as an event on the schedule. This method is much more efficient: you only compute when there is something to be done. One power of Swarm is that it supports both discrete event and time stepped models.

Figure 4. Time evolution of the world
Mousetrap-world1.png Mousetrap-world2.png Mousetrap-world3.png Mousetrap-world4.png

These are snapshots of the world over time (from early on through the end of the reaction). Mousetraps change from blue to red when the trap fires. Each time a mousetrap is triggered, it schedules two trigger events for two random nearby mousetraps sometime in the near future. The balls only fly a limited distance; that induces a spreading aspect to the reaction.

Figure 5. Model data

These two graphs show detail about the reaction rate. The top graph, the number of traps triggered over time, shows the classic result: the reaction initially spreads rapidly, but slows down and stops when it runs out of fuel (loaded mousetraps). The bottom graph is simply the number of events pending on the schedule, this corresponds to the number of ping pong balls currently in the air.


[Main Page]
Main page
About SwarmWiki
News
Recent changes
Random page
Help

View source
Discuss this page
Page history
What links here
Related changes

Special pages