Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351000

Summary:	[SD] Proposed changes for generated Execution behavior
Product:	[Modeling] AMP	Reporter:	Miles Parker <milesparker>
Component:	Escape	Assignee:	Miles Parker <milesparker>
Status:	NEW ---	QA Contact:	Miles Parker <milesparker>
Severity:	enhancement
Priority:	P3	CC:	jonas.ruettimann, urs.frei
Version:	0.9.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Miles Parker

2011-07-02 16:18:03 EDT

To continue from last bug, here is what I'm thinking *might* work for integrating stuff  with rules engine:

If we can treat the dynamic variables as special child attributes/state for the agents, then we can: 

a) Create a "Initialize Dynamic Variables" Initial Rule that would occur once and only once at the start of a model run. Then we wouldn't have to override executeOnMembers directly, which gets called for every model step.

b1) Create a "Calculate Dynamic Variables" Rule that would occur once for each variable update.

b2) Even better if we use the action approach proposed in the early bugzilla, the second rule would be created automatically. So if we created something like an AStock and AFlow rule, then each of those rules would be added as agent rules and fire once every model step with the appropriate semantics.

These would allow the SD aspects to be treated like all of other other behaviors in the generated model at runtime. (For example, in the Ascape Swing-based runtime, you can actually turn model behaviors on and off at runtime. It would be pretty easy to get that working for AMP as well. So in a bath tub model, you could interactively turn off and on the "drain" process, without having to change anything  else in the model.)

Comment 1 Jonas Ruttimann

2011-07-07 07:55:21 EDT

Hm... I think this discussion has move to the mailing list.

Comment 2 Miles Parker

2011-07-07 13:27:54 EDT

Right, we should probably try to move it back here. :) I'm not sure if we came to any conclusions there but I think the basic question is whether if we made something like these changes a) if this would cover all of your representational needs, and b) if that would meet your needs to have something that worked well for end-users.

Comment 3 Miles Parker

2011-07-07 21:45:37 EDT

OK, please see bug 351501. That provides basic support for integrating with stat colelctor directly so we don't have to go through indirection of what you're needing to do now.

But to support the next part, I would need to change some of the SD model so that it would extend existing metaabm models. I just realized that you're not actually extending metaabm at all. Is there a reason that you don't want to do this?

What I'm thinking of at this point will not change any actual functionality, it's just refactoring to support more consistent codegen:

Replace SdNamedElement with SNamed
Make SdAbstractVariable extend SAttribute*
Get rid of SdModel since we could just use SContext**

What I'm really aiming at there is to be able to use SD features directly as part of an ABM model and these changes would allow that as well as clean up the generated code quite a bit. This all might be too radical surgery for your existing models. We could maintain both to get


*I know there are some questions about whether they really are attributes but it would buy us a lot, and we could hide the stuff that you don't want in the editor.) Alternatively we could use a common base class perhaps IValue, but that would require a lot more refactoring on the codegen side.

**We could still support a separate node for Dynamic variables. Question is there an exact one-to-one coorespondence between SdModel and a given SAgent?