Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- geopro:pedro:swarm [2007/07/03 00:38] – created pedro
+++ geopro:pedro:swarm [2007/07/17 19:50] (atual) – pedro
@@ Linha 1: / Linha 1: @@
+====== Swarm ======
+//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.//
+\\
+{{  http://leg.ufpr.br/~pedro/figures/recursive-swarm.jpeg}}
+^**Homepage**  | http://www.swarm.org/wiki/Main_Page |
+^**Origin**    | Santa Fe Institute |
+^**Year**      | 1996 |
+^**Version**   | 2.2.3 |
+^**License**   | GNU-GPL |
+^**Language**  | Objective-C or Java |
+\\
+There is a GIS extension of swarm called [[http://www.gis.usu.edu/swarm/|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 [[http://br.geocities.com/alves_aq/swarm.en.html|here]]
+[[http://www.humboldt.edu/~ecomodel/software.htm|EcoSwarm]]: Tools for Ecological Models in Swarm
+\\
+==== The Swarm Simulation System: A Toolkit for Building Multi-agent Simulations====
+|N. Minar, R. Burkhart, C. Langton, M. Askenazi, | [[http://leg.ufpr.br/~pedro/papers/swarm-intro.pdf|pdf]]| [[http://scholar.google.com.br/scholar?hl=pt-BR&lr=&cites=14912459563270754412| 246 citations in Scholar]] (the book) |
+\\
+**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
+=====Swarm User Guide=====
+Available [[http://www.swarm.org/swarmdocs-2.1.1/userbook/userbook.html|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;
+  }
+===== space.h=====
+There is a class [[http://leg.est.ufpr.br/~pedro/papers/swarm-space.pdf|space]] (of 1997). It implements some concepts of a
+D 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.
+===== Examples available at swarm wiki=====
+[[http://www.swarm.org/index.php?title=Swarm:_applications&diff=3358&oldid=3357|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.
+=====TODO=====
+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.
-**Origin**      |
-**Year** |
-**Version** |
-**License**           |
- **Language**          |