Hi, Russ. As you might suspect from my previous comments, I have spent many years building models, most of them ABMs, many of them large distributed ones. What I have found over the years is that each problem domain is significantly different from other domains, meaning there there is very little generic agent behavior or functionality that could realistically be captured and reused in an "ABM framework".
There is some, however, and in fact I have built my own very lightweight framework (in C++) that uses it. I chose C++ because it is a language that is well-supported in HPC environments. In an abm, agents interact, and their interactions result in changes to the system to occur. Some of the changes to the system occur instantaneously; some interactions will cause a change to occur in the future. An example of the latter is when an agent causes disease to be be transmitted through interactions with other agents. After a latent period some or all of the infected agents will become symptomatic. My framework therefore has a mechanism to cause the simulation clock to advance as a result of agent interactions. My distributed agent framework also has an interface that allows agents to migrate between cpus on a distributed machine, and to send messages between agents residing on different cpus. It also has a mechanism to keep the distributed machine synchronized in time as part of the time update mechanism. That's all the framework does. All of the other logic that defines the agent interactions is written by the model developer. Since the framework is implemented in C++, agents are implemented as C++ objects. As with any well-designed OO code, the objects contain their state information as object member data, and their logic definitions (rules) as object member methods. There is a very simple API that allows the agents to recognize the system clock and to cause it to be updated as interactions dictate. That's where the framework functionality stops. There is no generic rule generation in the framework. There is no rule rewriting. The framework does not provide any generic genetic algorithms. There are no classes of agents. No doctor agent classes. No stock arbitrage agent classes. No hospital patient agent classes. No car agent classes. No house agent classes. No airplane agent classes. These are all examples of application-specific agent functionality that may or may not be required to implement an abm for a specific problem definition. This is my abm design methodology as it relates to implementation within my own abm framework: - The model developer defines his agents at a level of resolution that is sufficient to capture the information required to address the problem that (this specific) abm is intended solve. - The model developer identifies all state data that an agent will be required to maintain (for this specific abm). - The model developer identifies all of the (specific for this application) rule logic definitions which will control the interactions of the agents with each other, and within (this specific) simulation state-space. - The agents are implemented as C++ objects I looked at the AMP platform that Miles mentioned, and it appears to me to be extremely constraining, and not well-suited to implementing large abms as it only appeared to support serial, non-distributed compute architectures. I think I would feel like a slave to the AMP IDE were I to try to use it. I would prefer more flexibility that it seems to provide. Regards, --Doug On Mon, Aug 31, 2009 at 8:36 PM, Russ Abbott <[email protected]> wrote: > Hi Doug, > > I got Miles message as well, but I want to ask you about this one anyway. > I'd be interested to know what your answer to your question about added > value would be for you to think that an ABM framework is worth the trouble > to build. I'm not asking as a challenge but so that I have some guidance > about what you think would be valuable/important to include in our system. > > I'm copying Miles who may not actually be on the list. > > Miles, I'd be very interested in your answer also. How would you respond to > Doug's added-value question wrt AMF > > -- Russ > > > On Tue, Sep 1, 2009 at 11:35 AM, Douglas Roberts <[email protected]>wrote: > >> *"As I see it, Drools is essentially a layer above Java that supplies a >> great many of the capabilities I want. It doesn't have the notion of agent >> at all. But we can build that."* >> >> I think I get it. >> >> Layers of abstraction, piled upon more layers. That's the answer. I >> forget what the question was. >> >> I can get behind that (hey, I work for a living too). >> >> Aside: Warning flag #2 usually goes up when I see the words "Schwa, schwa, >> schwa, Framework, schwa, schwa" preceding the description of some >> historically-vetted simulation approach, or another. >> >> What I would really love to see is a concise statement of what the added >> value that this proposed approach is supposed to bring to the table. >> >> --Doug >> >> >> On Mon, Aug 31, 2009 at 6:54 PM, Russ Abbott <[email protected]>wrote: >> >>> Hi Miles, >>> >>> I got both of your messages. Thanks. >>> >>> Our situation is that we have embarked on building a framework based on >>> the [email protected], The Friday Morning Applied Complexity >>> Coffee Group <[email protected]>ols >>> Expert<http://jboss.org/drools/drools-expert.html>Rete rules engine. Drools >>> was developed within JBoss for controlling >>> distributed J2EE applications. It wasn't developed with agent-based modeling >>> in mind. Nonetheless I like it as a starting point for a number of reasons. >>> >>> - Its rule language is both simple and open. It supports get/set >>> operations on Java objects. So it it not limited to operating on any >>> particular category of things. In addition, the rule language allows any >>> java method call to be embedded within a rule. That may seem too open, >>> but >>> it allows new primitives to be added to the repertoire of agent >>> operations >>> very easily. The rules may be written in MVEL<http://mvel.codehaus.org/>, >>> which is a Java expression language. Although I'm not an expert in either >>> Drools or MVEL, my expectation is that one could embed a Genetic >>> Programming >>> capability within agents by using the MVEL parser. What's interesting >>> about >>> MVEL (from the little I've read about it) is that it's basically the >>> kind of >>> code that one would write in a Java method. That is, it doesn't have >>> class >>> declarations, but it supports Java procedural and evaluation constructs >>> within an expression-oriented framework. >>> - Drools allows one to add rules dynamically. >>> - One can instantiate as many Drools Rete engines as one likes. They >>> can share the same workspace. They can run in separate threads. >>> >>> As I see it, Drools is essentially a layer above Java that supplies a >>> great many of the capabilities I want. It doesn't have the notion of agent >>> at all. But we can build that. Each agent can have its own Rete engine and >>> run in its own thread. That would be the next layer. All this is still >>> really just Java libraries. In adopting Drools and building some agent-like >>> capabilities on top of it, we are not yet cutting off our ability to add >>> features in straight Java. >>> >>> Part of my vision is that the framework will support what I've been >>> calling service oriented agent-based modeling. That means that everything an >>> agent does can be understood as a service that another agent can make use >>> of. The simple paradigm is that an agent operates on objects in its >>> environment -- including possibly other agents. An agent rule would take >>> objects as input and produce either new objects or modified objects as >>> output. Clearly this is an extraordinarily simple paradigm. But I think it >>> supports a great deal of what I think we need in a modeling environment. >>> >>> Once we have that layer going, I'd like to develop mechanisms to hook >>> agents up in networks. (Again, something quite simple.) A simple version of >>> such a network within my basic paradigm is a supply chain. But the network >>> would allow loops and it would be dynamically reconfigurable. The agents >>> could restructure it as circumstances suggest. So what I'm saying here is >>> that a networking capability would be another layer in this framework. One >>> wouldn't be forced to use it, but it would be there. >>> >>> My question for you is what would you want to see as additional agent >>> support in a project that took this route? >>> >>> -- Russ >>> >>> >>> On Tue, Sep 1, 2009 at 9:22 AM, Miles Parker <[email protected]>wrote: >>> >>>> >>>> Hi Russ! >>>> >>>> I am developing two components that could be useful here. The AMP >>>> project itself is overall infrastructure for this kind of modeling, and you >>>> can use the olde Ascape API is you wanted for that. You can add rules in >>>> mid-run w/ Ascape *but* they apply to a collection of agents. An >>>> alternative >>>> is to roll your own rule sets and have them fired as part of a single >>>> Ascape >>>> rule. At least all of the other ABM stuff would be supported. >>>> >>>> The more directly aplicaable bit is the Agent Modeling Framework whihc >>>> is similar to the Eclipse Modeling Framework. There is a very high level >>>> represeentation for agent behavior using a Query->Control->Transofmration >>>> paradigm that would suit *I think* what you say well -- though it would be >>>> good to have an example to know for sure. Now.. the issue with AMF right >>>> now >>>> is that it is designed for static rules / behaviors. That is, the >>>> infrastructure uses code generation at design time, but there is no such >>>> limitation for models themselves -- but that is a distinction with a >>>> difference at the moment as there is no way to execute such agents. :). >>>> Marcus Daniels especially has convinced me of the importance of >>>> self-modifying/dynamic rulesets and I think it is also a potential big >>>> advantage of the Meta-Model approach because it provides clean high-level >>>> semantics. One (of many many) things that I would love to see happen with >>>> AMF is a dynamic / interpreted run time for self-modifying models. EMF does >>>> a similar thing quite well and there is no reason that in principal this >>>> couldn't be done with AMF. Basically, instead of generating code that maps >>>> the high-level AMF description to some existing API toolset (e.g. Repast, >>>> Ascape) you'd have an execution environment that loaded an AMF model and >>>> then invoked API calls through reflection. Obviously you'd take a >>>> performance hit but if you had nice high-evel APIs that mapped well to the >>>> AMF meta-model it needn't be huge. >>>> >>>> Sorry if this is somehwat confused but hopefully enough info to see if >>>> there is any potential here. >>>> >>>> cheers, >>>> >>>> Miles >>>> >>>> On Aug 23, 2009, at 2:15 PM, Russ Abbott wrote: >>>> >>>> Hi Miles, >>>> >>>> We exchanged some mutually appreciative emails some time ago but haven't >>>> spoken in quite a while. I hope things are well with you. >>>> >>>> I'm looking for an ABM framework in which (a) agents are driven by >>>> forward chaining rules (i.e., a "blackboard" system) and (b) those rules >>>> are >>>> themselves first class citizens in the model so that, for example, an agent >>>> can create a new agent with dynamically generated rules or an agent can >>>> modify its own rules dynamically. >>>> >>>> Owen Densmore of the FRIAM group suggested (see below) that you may be >>>> working on something like this. Are you? I can't find the reference Owen >>>> referred to. >>>> >>>> Thanks, >>>> >>>> -- Russ Abbott >>>> _____________________________________________ >>>> Professor, Computer Science >>>> California State University, Los Angeles >>>> Cell phone: 310-621-3805 >>>> o Check out my blog at http://russabbott.blogspot.com/ >>>> >>>> >>>> >>>> On Sun, Aug 23, 2009 at 11:17 AM, Owen Densmore <[email protected]>wrote: >>>> >>>>> Isn't this close to Miles Parker's latest work? His WedTech talk >>>>> seemed to suggest that. His proposal was accepted, and he's got a project >>>>> page: >>>>> http://www.eclipse.org/amp/ >>>>> .. he may have become less ambitious in the rule-driven approach, not >>>>> sure. >>>>> >>>>> -- Owen >>>>> >>>>> >>>>> >>>>> On Aug 22, 2009, at 9:58 PM, Stephen Guerin wrote: >>>>> >>>>> Russ, >>>>>> >>>>>> I haven't seen a system like your describing. It shouldn't be too hard >>>>>> to assemble though if the rule grammar was simple. >>>>>> >>>>>> -S >>>>>> --- -. . ..-. .. ... .... - .-- --- ..-. .. ... .... >>>>>> [email protected] >>>>>> (m) 505.577.5828 (o) 505.995.0206 >>>>>> redfish.com _ sfcomplex.org _ simtable.com _ lava3d.com >>>>>> >>>>>> On Aug 22, 2009, at 9:13 PM, Russ Abbott wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> I'm interesting in developing a model that uses rule-driven agents. I >>>>>>> would like the agent rules to be condition-action rules, i.e., similar >>>>>>> to >>>>>>> the sorts of rules one finds in forward chaining blackboard systems. In >>>>>>> addition, I would like both the agents and the rules themselves to be >>>>>>> first >>>>>>> class objects. In other words, the rules should be able: >>>>>>> • to refer to agents, >>>>>>> • to create and destroy agents, >>>>>>> • to create new rules for newly created agents, >>>>>>> • to disable rules for existing agents, and >>>>>>> • to modify existing rules for existing agents. >>>>>>> Does anyone know of a system like that? >>>>>>> >>>>>>> -- Russ >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> ============================================================ >>> FRIAM Applied Complexity Group listserv >>> Meets Fridays 9a-11:30 at cafe at St. John's College >>> lectures, archives, unsubscribe, maps at http://www.friam.org >>> >> >> >> >> -- >> Doug Roberts >> [email protected] >> [email protected] >> 505-455-7333 - Office >> 505-670-8195 - Cell >> > >
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
