Process domains do not work well inside non-process domains

[cxbrooks]

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#5 From: @cxbrooks Reported version: 4.1

[cxbrooks]

PN does not work inside DE. I fixed the error message so that it is more clear and I added a test to pn/test/PNInsideDE.xml that illustrates the problem.

We need to have a set of tests that illustrates what domains work inside what other domains.

Below is some email from Ptolemy-hackers on 12/15/04 and 12/16/04

--start-- Edward Lee wrote:

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.

Ivan Jeukens wrote:
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.

--end--

[cxbrooks]

Added ptresearch as QA Contact

[cxbrooks]

See $PTII/doc/domainCompatibility.htm for a list of what works where.

[cxbrooks]

Our paper and notes about domain compatibility can be found at http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/domainCompatibility.htm

There is quite a bit of complexity here, in part because the Continuous domain is a redesigned CT domain. Also, the blurring of CT/DE/SR adds to the complexity.

The next step in this bug is to go through the chart and create test cases for each interaction that should work. We should start with the non-experimental domains (CT, DDF, DE, FSM, PN, Rendezvous, SDF, SR, Wireless) and make sure that each of the combinations in the domain compatibility chart has a working, useful example.