|
From: Andy C. <ac...@ll...> - 2003-02-25 01:50:17
|
[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. ============================================ |