Posture? Russ asked for my input; I gave it to him.
And that's my posture on this issue. ;-} On Tue, Sep 1, 2009 at 10:29 AM, Miles Parker <[email protected]> wrote: > > OK, I'm going to sign off this discussion now. Don't really care enough to > posture like this. > > On Sep 1, 2009, at 5:13 AM, Douglas Roberts wrote: > > 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
