Yes, it looks as if the code is designed so that process domains (PN, CSP) can only be used within process domains. I'm not sure to what extent this is a limitation of the process domains vs. a semantic problem. What would PN mean within DE? Since PN has no well-defined notion of a "firing", how would you assign time stamps to the outputs of a PN actor? By default in DE, the time stamps of the outputs of an actor match those of the inputs that triggered the firing. There is no such notion in PN.
I think that until there are clear answers to the semantics questions, there is not much point in trying to make the software support the combination. On the other hand, trying to make the software support these combinations is likely to yield deeper insights into the semantics questions. I would encourage you (or anyone else) to do this... It would be an excellent research topic.
Edward
At 09:33 AM 12/15/2004 +0000, Ivan Jeukens wrote:
> Hi all, > > I think there is a problem with the process domains, in particular, csp > and pn. I'm working >on a specification that mix CT, DE, CSP and SR. When CSP is used inside a >DE topology, >exceptions are thrown (something related to the addBranches method of the >BranchController class). >I have attached a simple specification that reproduces the bug. > > Ivan > > > >> "http://ptolemy.eecs.berkeley.edu/xml/dtd/MoML_1.dtd"> > > > class="ptolemy.kernel.attributes.VersionAttribute" value="4.0.1"> > > > class="ptolemy.domains.de.kernel.DEDirector"> > > value="[100.0, 60.0]"> > > > > class="ptolemy.actor.gui.WindowPropertiesAttribute" value="{bounds={76, > 83, 983, 603}, maximized=false}"> > > > value="[763, 497]"> > > > class="ptolemy.data.expr.ExpertParameter" value="1.0"> > > > class="ptolemy.data.expr.ExpertParameter" value="{381.5, 248.5}"> > > > Create a sequence of tokens with increasing value > > value="[115.0, 295.0]"> > > > > > value="[280.0, 295.0]"> > > > class="ptolemy.domains.pn.kernel.PNDirector"> > > class="ptolemy.kernel.util.Location" value="{45, 70}"> > > > > > > class="ptolemy.kernel.util.Location" value="{20.0, 200.0}"> > > > > > > class="ptolemy.kernel.util.Location" value="{580.0, 200.0}"> > > > > > value="2"> > > > class="ptolemy.vergil.icon.AttributeValueIcon"> > > class="ptolemy.kernel.util.StringAttribute" value="factor"> > > > > class="ptolemy.kernel.util.Location" value="[265.0, 200.0]"> > > > > > > > > > > > > > class="ptolemy.actor.lib.gui.SequencePlotter"> > > value="{470, 290}"> > > >>"http://ptolemy.eecs.berkeley.edu/xml/dtd/PlotML_1.dtd"> > >SequencePlotter > > >?> > > > > > > > > > > >
------------ Edward A. Lee, Professor 518 Cory Hall, UC Berkeley, Berkeley, CA 94720 phone: 510-642-0455, fax: 510-642-2718 eal@eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu
> > Yes, it looks as if the code is designed so that process domains (PN, > CSP) > can only be used within process domains. I'm not sure to what extent > this > is a limitation of the process domains vs. a semantic problem. What > would > PN mean within DE? Since PN has no well-defined notion of a "firing", > how would you assign time stamps to the outputs of a PN actor? By > default > in DE, the time stamps of the outputs of an actor match those of the > inputs > that triggered the firing. There is no such notion in PN.
Yes, I agree with you, not all combinations are meaningful. As a matter of fact, I was combining CSP inside a SR topology. That does not seem right because of the synchronous hypothesis. But, I was testing a tool for checking the validity of specifications against certain MoCs, and in principle, that combination (SR + CSP) was ok (the specification isn't timed, is monotonic, etc).
As for DE + CSP I think it might be useful, since DE is primary a simulation model, as is CT. Therefore, these two models are pretty good for capturing the environment of a system. In my particular case, I'm also interested in embedded software, so CSP an PN should be put in the mix.
Indeed, trying to view a "process composite actor" as a "activation based atomic actor" is tricky. The "fire until deadlock" policy for the process composite seems the way to go. If no actor inside the composite manipulates the time value, i.e the composite is zero delay, then the timestamps of produced events could be of current time of firing. Now for generating embedded software, I think it does not make much sense the notion of timestamp of an event, since the real time is not a controllable feature. Maybe the only acceptable method of a process that manipulates time is a timed delay ( fireAt() ) . In a DE + process this can be interpreted as the generation of a pure event that will trigger a future activation of the process based composite. Anyway, issues of deadlocks, livelocks and determinacy should be studied carefully.
Regards, Ivan
P.S.: By April/May of 2005 I should get my PhD, and be a free man. So, if anyone out there is interested in a 6 year experienced Ptolemy II guy to develop MoC science, just let me know ... :-)
---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: ptolemy-hackers-request@ptolemy.eecs.berkeley.edu
