[Repast-developer] agent base interface

[Andy C. <ac...@ll...>]

[note to self: replies to email lists work better when you make sure they 
go to the *list* instead of the author of the last post... DOH!]

At 02:20 PM 2/23/2003 -0500, you wrote:
>In my model, I apply a different encapsulation of functionality, my 
>solution tends to rely heavily on a class I call Landscape.  Landscape is 
>a "wrapper" around an agentList, agentGrid, habitatGrid, and Birth queue 
>(like those found in SugarModel). My Agents encapsulate their own 
>"dispersal capabilites" and use methods available in the landscape wrapper 
>to move, the landscape also wraps the capability to add an agent to the 
>"grid/agentList" into a single method.
>
>Movement rules are defined in the agent, the ablitiy to move is done by 
>calls to landscape.moveAgentTo(agent,x,y). Agents are capable of 
>reproducing new agents, which is done by the parent agent creating a new 
>agent and letting it "disperse" from the point of the parent agent, if 
>successful, it is added to the landscape at that point. Birth and Death 
>are done by updating the landscape at the end of an iteration, which 
>clears all "dead" agents and adds all the new agents in the birthQueue to 
>the agentList.
>
>With my current strategy, I like the fact that the behavior for addition, 
>"alteration of position" and removal of agents is encapsulated in the 
>Landscape "wrapper" itself. One can write different Landscapes to get 
>different updating behaviors, one can write new agents with different 
>movement rules, survivorship and reproduction capabilites. While 
>"decisions agents can make" are encapsulated in the agent,  the methods of 
>the landscape solidify the "update" environments rules and keep them "out 
>of reach" of the agents themselves.
>
>-Mark

On the subject of "ABM design patterns", this matches one that I have 
internally been calling the "Referee" design pattern. The idea in this 
pattern is to separate the decision of what agents want to do from the 
determination of what actually happens. The "Referee" is an object that 
sits between the agents and other agents and the environment that 
determines resolution of conflicts if you will. Here, the Landscape seems 
to play this role almost exactly, and Mark's reasons for the Landscape 
match my own thinking pretty much exactly (I'll leave it to Mark to decide 
if resembling my thinking is a good thing or not... ;-)

A canonical example to me is conservation: if agent A and agent B 
simultaneously do something that would result in an exchange of something 
between them and that exchange must not violate conservation (e.g. one gets 
20 bucks but the other gives 10 is a bad thing), a referee may be a nice 
way to ensure (insure?) conservation. Instead of either A or B determining 
unilaterally what they think happens in the transfer, they "submit their 
case" to the referee, who then informs them of the results, thus 
guaranteeing that they both "see" the same amount being transferred.

As Mark says, the pattern works well to separate the decision making of 
agents from the "resolution" of the physics or other rules of interaction 
that the simulation is interested in. I submit that this is one step 
towards making agents more interchangeable from simulation to simulation 
(IOW, making it more likely that agents created by one team may be plugged 
into a simulation created by another): the agents just make decisions, but 
the choice of what those decisions actually *do* is encapsulated in the 
referee. Within broad limits, agents may be able to function reasonably 
well in a variety of different but somewhat related simulations. I also 
think this pattern helps the modeler try to determine the drivers of their 
system: they can run the simulation with different factors turned on and 
off just by changing the referee, instead of having to go back and change 
all of the agents themselves as they have to do if the "physics" is encoded 
in the agents themselves, and by doing so they can get a feel for which 
"rules" are the ones that truly drive their system, and which others are 
pretty superfluous. If you have a simulation of a bunch of particles flying 
around, say, is air friction is important? Well, run it twice, one with air 
friction turned on in the referee, one with it turned off, and compare the 
results. If they look similar, air friction probably wasn't a driver at 
this level of the system...

So I'm wondering if anyone else uses such a pattern wherein the "rules" are 
encapsulated in a single object and the agents themselves concentrate only 
on maintaining their own internal state and making their own decisions?

Cheers,
Andy

============================================
Andrew J. Cleary, Software Engineer/Computational Scientist
Lawrence Livermore National Labs, 925-424-5890.
============================================