[kepler-users] PN directors - mixing workflows

Wed Nov 23 09:03:38 PST 2011

Hi Michael,
PN can be embedded inside PN, but it is best not to do so.  Probably the 
paper should have a footnote for PN/PN that indicates that there are 
serious limitations.   In theory, PN works inside PN.  In practice, it 
is not such a good idea.

Below is the text that describes PN in PN from the paper:
--start--
PN. The PN director is apparently the least restrictive in the
actors it can manage, but also the least useful in an opaque
composite actor. The reason for this is very fundamental. If the
PN director were to define a finite fire() method, what should that
method do? Each of the actors under its control is executing in its
own thread of control. How much execution should be performed?
One possible answer is ``as little as possible,'' but this would result
in nondeterminate execution. If two actors have threads that are
able to perform computation, which should be allowed to perform
computation? The only other obvious answer is ``as much as
possible''. This can be made determinate, but typical PN workflows
can execute forever if given the opportunity. Hence, this yields an
infinite execution. PN is sufficiently expressive that determining
whether this execution is infinite is equivalent to solving the
famous halting problem in computation, and hence is undecidable.
This property of PN explains why it is challenging to introduce a
model of time to PN. Specifically, timed variants of PN that have
appeared in the literature allow time to advance when the model
deadlocks. But whether the model deadlocks is undecidable, and
typical models never deadlock. Thus, the loosest abstract semantics
comes at a serious price, an inability to introduce a model of time.
For example, the workflow of Fig. 1 with PN on the outside
would be hard to reuse inside others. It follows that, when a
workflow has potential to be reused inside others, PN should be
avoided and, if possible, replaced by a more reusable director.
Moreover, models that require time to advance cannot be used
within PN.

--end--

It looks like the link to Antoon's website that provides further 
information is broken.
I've sent him email to see if we can get the link fixed.  In the 
meantime, there is

http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/domainCompatibility.htm

That page has a link to ptolemy/domains/pn/test/PNPNSleep.xml, which 
runs but produces error messages on standard out, much like one of your 
test cases.  PNPNSleep.xml never leaves the wrapup stage. I've attached 
that model.

I opened your models, exported the xml and stripped out the Kepler 
specific code so that Ptolemy users can open them.

See below for some other comments.

On 11/23/11 2:38 AM, Michal Owsiak wrote:
> Hi,
>
> I am trying to embed PN based composite actor within PN workflow. My 
> motivation is driven by the existing workflows which I want to combine.
>
> However, I have encountered some issues.
>
> First things first. If I understand this paper right:
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-139.pdf
>
> It should be possible to embed PN within PN (Table 1).
>
> However, if I try to do so I am getting errors.
>
> 1. In case of "Will never start.kar" Kepler wraps up and nothing happens.
>
> 2. In case of "012 - Simple - PN inside PN.kar" I am getting an 
> exception.
>
> ptolemy.kernel.util.IllegalActionException: Receiver in the port: 
> .Simple - PN inside PN.CompositeActor.output is not a consumer receiver
>
> 3. In case of "013 - Simple - no domain inside PN.kar" everything is 
> fine.
>
> Why there are such differences in embedding PN inside PN?
>
> Another question is. According to the paper:
>
> "To determine which combinations are possible, we need to know two 
> things about a director:
> 1. What properties it assumes of the actors under its control, and
> 2. What properties it exports via the opaque composite actor in which 
> it is placed.
> If a director's exported properties match those assumed by another 
> director, then it can be used within that other director"
>
> Is there any way of checking mentioned properties automatically?
In theory, if an actor is designed and implemented according to the 
coding standards, then it should work under all models of computation.  
In practice, some actors are model of computation-specific.   There are 
a few rules of thumb, like fire() should not change the state because 
models of computation like the continuous domain may call fire() 
multiple times.  The coding standards are defined in the designing 
actors chapter in Volume I of the Ptolemy design doc, see 
http://ptolemy.eecs.berkeley.edu/ptolemyII/designdoc.htm
> What I mean here is - how can I decide which actor comply to 
> director's expectations? I want to base the decision neither on 
> documentation nor on experiments. I'd like to have general rule for 
> checking.
I don't know of a general rule.  My guess is that it would be impossible 
to define static analysis rule that would work for any Turing complete 
language.  What we have instead are guidelines.  Creating test cases 
(experimenting) also helps.
>
> What I imagine here is some sort of "script" that goes over actors' 
> classes/kars and by checking some properties (which?) tells whether 
> actor can be executed in given domain or not. Is that possible at all? 
> At least in theory?
I don't think it is possible, but perhaps someone can correct me.

I think that having standards and heuristics is one way to go.  If the 
code has been inspected and there are test cases for the different 
domains, then it is known that the actor will work for some combinations.

_Christopher
>
> Thanks in advance for your support.
>
> Regards
>
> Michal Owsiak
>
>
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111123/bc9f3291/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Simple2PNInsidePN.xml
Type: text/xml
Size: 32093 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111123/bc9f3291/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimplePNInsidePN.xml
Type: text/xml
Size: 27620 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111123/bc9f3291/attachment-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WillNeverStart.xml
Type: text/xml
Size: 23926 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111123/bc9f3291/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PNPNSleep.xml
Type: text/xml
Size: 8183 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111123/bc9f3291/attachment-0003.xml>