Swarm is a multi-agent software platform for the simulation of complex adaptive systems. Swarm supports hierarchical modeling approaches [and] provides object oriented libraries of reusable components for building models and analyzing, displaying, and controlling experiments on those models.

There is a GIS extension of swarm called kenge (last updated in 1999, with little internal details and no source code. Basically it can load data exported from GIS to files in some format)

How to compile swarm in ubuntu here

Available here

Most swarm applications have a structure that roughly goes like this. First, a top level - often called the “observer swarm” - is created. That layer creates screen displays and it also creates the level below it, which is called the “model swarm”. The model swarm in turn creates the individual agents, schedules their activities, collects information about them and relays that information when the observer swarm needs it. This terminology is not required by Swarm, but its use does facilitate it.

Current priorities for the Swarm team […] include the further generalization of Swarm to be useful on a broader array of platforms and in conjunction with additional computer languages. Prototype XML and Scheme layers for Swarm have been tested, for example.

One agent always inherits the class SwarmObject, and has a description such as

@interface Heatbug: SwarmObject
{
  double unhappiness;                 // my current unhappiness
  int x, y;                   // my spatial coordinates
  HeatValue idealTemperature;             // my ideal temperature
  HeatValue outputHeat;               // how much heat I put out
  float randomMoveProbability;            // chance of moving randomly

  id <Grid2d> world;                  // the world I live in
  int worldXSize, worldYSize;             // how big that world is
  HeatSpace *heat;                // the heat for the world
  Color bugColor;                 // my colour (display)
}

When those objects are no longer needed, the program can send that object the drop message, which removes it from memory.

We define the scheduler of agents inside of them, and each agent has a buildActions method.

[…] when the observer swarm needs a list of all the agents in a simulation in order to create a graph, the model swarm should have a method, such as getAgentList, that returns a list of agents that the observer swarm can use.

buildActions 
{
  modelSchedule=[Schedule createBegin: self];
  [modelSchedule setRepeatInterval: 1];
  modelSchedule = [modelSchedule createEnd];

  [modelSchedule at: 0 createActionTo: aBug message: M(step)];

  return self;
}

[modelSchedule at: 0 createActionForEach: bugList message: M(step)];

The library space provides 9 classes:

• GridData: basic class. getObjectAt (an agent), getValueAt (an integer value)
• Discrete2d: Currently Discrete2d grids are accessed by integer pairs of X and Y coordinates. create(xsize, ysize), putObject (agent), putValue (integer)
• DblBuffer2d: double buffered space. Two lattices are maintained: lattice (the current state), and newLattice (the future state).
• Ca2d: abstract protocol for cellular automata
• Value2dDisplay: displays 2d arrays of values
• ConwayLife2d: Classic 2d Conway's Life CA
• Diffuse2d: 2d difussion with evaporation
• Grid2d: A 2d container class for agents. It gets most of its behaviour from Discrete2d, [and] check that you don't overwrite things by accident. Only one object can be stored at a site, no boundary conditions are implied, etc.
• Object2dDisplay: displays 2d arrays of objects
• Int2dFiler: (deprecated) save the state of any Discrete2d: object (or a subclass thereof) to a specified file.

Downolad (last updated in 2005)

There is a class space (of 1997). It implements some concepts of a 2D space, but each cell can have only one object, and they are referred as (x,y) coordinates. They have a to do list: Briefly, coordinates need to be elevated to the status of objects, which should hopefully allow spaces of different scales and boundary conditions to interact through a common reference system. In addition, other types of spaces are desired: continuous coordinates, other dimensions, arbitrary graphs, etc.

Everything related to the space is up to the programmer. For example, in the implementation of Schelling's model of segregation, the following code shows an example of going through the neighborhood (/home/pedro/codigo/swarm/swarmapps-objc-2.2-2/schellingII/Person.m):

for(i = -radius; i< radius + 1; i++)
{
  int xcoord = x+i;
  if ( xcoord< 0 || xcoord >= xsize)
  {
    if (edgeWrap == NO) continue;
    else xcoord = [self wrapXCoord: xcoord];
  }
    
  for(j = -radius; j< radius +1 ; j++)
  {
    int ycoord = y+j;
    if ( ycoord< 0 || ycoord >= ysize)
    {
       if (edgeWrap == NO) continue;
       else ycoord = [self wrapYCoord: ycoord];
    }
    if( (neighbor = [[myWorld getObjectGrid] getObjectAtX: xcoord Y: ycoord] ))
    {
       numNeighbors++;
       if([neighbor getColor] == t)
         sumSimilar++;
    }
  }
}

In this edition, there is also some trivial clarification/reorganization of the interface between the agents and the SchellingWorld. The Schelling world has several collections/spaces in it. It has an “objectGrid”, a Swarm Discrete2d that records the positions of the agents. It also has the array of Nhood2dCounters, each of which tells how many of a color are visible. […] when an agent moves, he just tells SchellingWorld to remove it, or add itself. In Person.m, for example:

    [myWorld removeObject: self atX: x Y: y];
    [myWorld addObject: self atX: newX Y: newY];

The SchellingWorld does the bookwork of putting agents in and out of objectGrid and also updating the Nhood2dCounter objects. I verified that this does give the right numbers.

From this we can see that Swarm works with a geometrical (and not topological) space (is that useful?). Note that this registering in the space is very useful to determine the interaction of agents in the space. When an agent registers itself in some spatial location, it can be referred by any other agent that wants to interact with someone in that cell.

rand_move: p 
{
    id loc;

    do{
        loc=[self getRandLoc];
    } while([world at: loc]!=nil);

    [p moveTo: loc];
    return self;
}

Swarm is a multi-agent software platform for the simulation of complex adaptive systems. In the Swarm system the basic unit of simulation is the swarm, a collection of agents executing a schedule of actions. Swarm supports hierarchical modeling approaches whereby agents can be composed of swarms of other agents in nested structures. Swarm provides object oriented libraries of reusable components for building models and analyzing, displaying, and controlling experiments on those models.

[…] collection of independent agents interacting via discrete events. […] There are no domain specific requirements such as particular spatial environments, physical phenomena, agent representations, or interaction patterns. Swarm simulations have been written for such diverse areas […]

The basic unit of a Swarm simulation is the agent. An agent is any actor in a system, any entity that can generate events that affect itself and other agents. Simulations consist of groups of many interacting agents. […] Simulation of discrete interactions between agents stands in contrast to continuous system simulations, where simulated phenomena are quantities in a system of coupled equations.

In addition to being containers for agents, swarms can themselves be agents. […] an agent can also itself be a swarm: a collection of objects and a schedule of actions. In this case, the agent's behavior is defined by the emergent phenomena of the agents inside its swarm. Hierarchical models can be built by nesting multiple swarms, as shown in the figure below.