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. From the floatspace example: A datafile object […] reads in GIS data and assigns a certain data value of a geographical coordinate to a cell object residing at the corresponding coordinate. A cell, therefore, has variables of these geographical data and whether any agents are staying at its coordinate or not.)

How to compile swarm in ubuntu here

EcoSwarm: Tools for Ecological Models in Swarm

Abstract: 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.

Swarm has the following components:

• SwarmObject: All agent classes inherit behavior from it. SwarmObject defines the basic interface for memory management as well as the support for probes.
• Swarm: Model swarms and observer swarms are written by using code inherited from this base class.
• Activity: defines the scheduling data structures and execution support.
• Simtools: classes to control the execution of the entire simulation apparatus: a fully graphical and a batch mode.

Ambiguity can occur in partial orders and time-based schedules as a result of two or more actions scheduled at the same time or in the same relative order. Swarm resolves such ambiguity by defining a “concurrent group type,” an explicit indication of how to execute a group of actions that are defined at the same time. Options include running the group in an arbitrary, fixed order running the group in a random order every time or actually running each action concurrently, for future implementation on parallel machines. The explicit notation of a concurrent group type helps to expose and remove any hidden assumptions in the time structure of a model.

TerraME: this control of ambiguity can be very interesting

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 Person: SwarmObject {
    int x, y;
    int xsize,ysize;
    int myColor;
    int unhappy;
    int nhoodType;
    int radius;
    int idnumber;
    double myTolerance, fracMyColor;

    BOOL edgeWrap;
    BOOL moved;
    SchellingWorld * myWorld;
}

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.

The ModelSwarm controls the application, contains the world and the set of agents.

@interface ModelSwarm : Swarm {
    // [...]
    id <List> agentList;
    id world;
}

// functions of the class
// [...]
stepThroughList;
getAgentList;

The ModelSwarm defines a scheduler of actions it will execute, and it sends “step” messages to the agents.

buildActions
{
    [super buildActions];    // super is the class this object inherits
    id modelActions = [ActionGroup create: self];
    [modelActions createActionTo: output message: M(step)];

    [modelActions createActionTo: self message: M(stepThroughList)]; // function to activate the agents it controls
    if (synchronous)
        [modelActions createActionTo: world message: M(stepRule)];

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

    [modelSchedule at: 0 createAction: modelActions];
    return self;
}

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.

From the paper below: The current space library is merely a suggestion of the kinds of environments a model could use: in the future, we plan to have spaces with continuous values and dynamics defined by differential equations. Spaces with other topologies are also crucial: three dimensions, non-discrete coordinates, and arbitrary graph structures are all needed by applications.

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)

Despite the representation of the space (always a grid) and its limited functionality, everything else 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 findEmptyLocationX: &newX Y: &newY]
[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. But the functions of SchellingWorld are implemented by the programmer.

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.

The next example shows how an agent moves in the space. It is from the example heatbugs:

rand_move: p 
{
    id loc;

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

    [p moveTo: loc];
    return self;
}

TerraME: The concept of region fits in this case. We could have a region storing the empty cells, and use it instead of searching the whole cellular space. We would need functions such as “add” and “remove” to the regions, and some support to randomness.

The creation of a group of agents, by a Model Swarm. Note that the model creates and puts it in the world.

for(i = 0; i < 100; i++)
{
    StupidBug* stupidBug = nil;

    stupidBug = [StupidBug create: modelZone];
    [stupidBug setWorld: world];
    [stupidBug setRandPosition];

    [bugList addLast: stupidBug];
}

TerraME: It could be possible to create all the set of agents, and then insert the whole group in the scale. At this moment, each agent chooses his position/trajectories in the space.

Some applications using swarm:

• Schelhorn, T., O'Sullivan, D., Hakley, M. and Thurstain-Goodwin, M. (1999), STREETS: An Agent-Based Pedestrian Model, Centre for Advanced Spatial Analysis (University College London): Working Paper 9, London.
• Haklay, M., O'Sullivan, D., Thurstain-Goodwin, M. and Schelhorn, T. (2001), '“So Go Downtown”: Simulating Pedestrian Movement in Town Centres', Environment and Planning B: Planning and Design, 28(3): 343-359.
• Batty, M., Desyllas, J. and Duxbury, E. (2003), 'Safety in Numbers? Modelling Crowds and Designing Control for the Notting Hill Carnival', Urban Studies, 40(8): 1573-1590.

Swarm learning curve:

• Najlis, R., Janssen, M.A. and Parker, D.C. (2001), 'Software Tools and Communication Issues', in Parker, D.C., Berger, T. and Manson, S.M. (eds.), Meeting the Challenge of Complexity: Proceedings of a Special Workshop on Land-Use/Land-Cover Change, Irvine, California.