One other thing, just to point out a bit of the flavor for where I think we can go with this, check out:
I think perhaps you can see that there is a sense of both SD and ABM here.
On Jul 6, 2011, at 2:10 PM, Miles Parker wrote: On Jul 6, 2011, at 1:32 PM, Miles Parker wrote:
Hi Urs,
On Jul 6, 2011, at 12:37 AM, Urs Frei wrote: Why the extra baggage?
For our very first steps with SD in
AMP we've used Agents, Attributes and Rules to model SD. No extensions
to AMP, to changes. Just pure AMP without SD plugins. It works. But it's
seens to us like workaround.
What if I could set it up so that all the end user had to do was to create a dynamic variable (special attribute) and the related action were created automatically in the background without the user doing anything else?
OK, but it works, which is a good thing.
Our modelers are SD modelers. They don't
know Agent Based modeling. They need an easy workflow with the metaabm
model. The need model components like Stocks, Flows, etc. So adding an
Agent with Attributes and Rules just to represent a Stock or a Flow doesn't
seem like the way to go.
That all makes a lot of sense, thanks for clarification. I think that we have a somewhat different philosophical take which is why this has been confusing. My bottom-line goal is always to try to create as universal *representation* as possible. Your bottom-line goal is to make a tool that works naturally for your users and that isn't a complete pain for you to maintain, and probably so that we don't have to have a long conversation every-time a change is made. :)
Your goal makes complete sense. For me the overall vision of AMP requires having some kind of fully integrated solution, and so that's what I've been striving to achieve. But these two goals aren't exclusive. We can move toward them from different directions over time. The key is to separate some of the presentation and editing concerns from the underlying representational concerns and paradoxically to better integrate some others. We also definitely need more high-level abstractions which is why something like the IAgentChild thing makes sense. For one thing, we can't assume that an EMF containment relationship (Contexts/Scapes/Agents) is the same thing as a Model containment relationship (Nations/People, Cities/Nations, Cities/People).
We wanted SD to be an extension to AMP
because Agent Based modelers probably don't want to bother with any SD
fragments. Only a modeler that has installed SD plugins is supposed to
see SD components in the metaabm editor.
When creating the extension point on
the metaabm model, we didn't want to create an extension __only__ for SD.
Who knows, one day someone might want to add a Discrete Event extension.
Or anything else. That's why the extension was created in a very generic
way. The extension (realized with a list of IAgentChild) is __not__ SD
specific. That's why we didn't want to call it "Dynamic Variables".
It's just a child of an Agent.
Yes, I think this is a very important design contribution -- I didn't mean that I thought it was a bad idea. Sorry if I gave that impression. I just want to get some of that innovation back into the main model and I want to figure out how to do that while preserving what you want.
For IAgentChild right now, could you clarify for me if there is a deep semantic difference between an Agent Child and a Context with a Child "Agent" (I don't think we should actually call it an agent, because in .acore it will be a state container that can be combined with an action container) that has some state? Because if not, on the implementation side it would be a lot cleaner to do the following:
1. Create a singelton agent that has that state, or simply add that state to the containing context. 2. Create or use a singleton agent to manage updates to that state.
This way all of the Ascape / Escape updating mechanisms and data collection could be used.
PS: As you know, Jonas and I are only
able to work frequently on AMP. Right now we're switching back to other
software development projects. So don't take it personally if we won't
respond as quickly as right now.
I am also going to be spending some time working on other stuff and thanks for keeping me up to date on that.
cheers,
Miles
Von:
Miles Parker <milesparker@xxxxxxxxx>
An:
AMP developer mailing
list <amp-dev@xxxxxxxxxxx>
Datum:
05.07.2011 19:41
Betreff:
[amp-dev] Better
SD / AMF integration
Gesendet von:
amp-dev-bounces@xxxxxxxxxxx
I really need feedback on these. I'm pretty sure I
can make the SEIR model work just fine without all of the extra modeling
baggage, but there may be something I'm still missing here, because it
just doesn't seem that complicated to me:
1. Agents have state as quantities.
2. Those quantitates can change dynamically over time based on rates and
between quantities (sources and sinks).
I can't see why this doesn't fit in with the basic hierarchical AMF Action
design with some modifications. I know that I don't see anything semantically
in the example model that can't be represented in the existing AMF model
with some new Action additions. Check out ADiffuse for an example of how
that can work.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350999
https://bugs.eclipse.org/bugs/show_bug.cgi?id=351000
_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
________________________________________________________________
Urs Frei, Ingenieur FH
Wissenschaftlicher Mitarbeiter
Fon +41 71 226 12 22
Fax +41 71 226 12 13
Web http://www.fhsg.ch
FHS St.Gallen, Hochschule für Angewandte Wissenschaften
IMS-FHS | Poststrasse 28 | Postfach 1664 | 9001 St.Gallen | Switzerland
FHO Fachhochschule Ostschweiz_______________________________________________
amp-dev mailing list
amp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/amp-dev
______________________________ Miles T. Parker President and Chief Software Architect Metascape, LLC Project Lead Eclipse Agent Modeling Project
tel: 509-643-4441 skype: milestravisparker ______________________________
|
