<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Michael,<br>
    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.<br>
    <br>
    Below is the text that describes PN in PN from the paper:<br>
    --start--<br>
    PN. The PN director is apparently the least restrictive in the<br>
    actors it can manage, but also the least useful in an opaque<br>
    composite actor. The reason for this is very fundamental. If the<br>
    PN director were to define a finite fire() method, what should that<br>
    method do? Each of the actors under its control is executing in its<br>
    own thread of control. How much execution should be performed?<br>
    One possible answer is ``as little as possible,'' but this would
    result<br>
    in nondeterminate execution. If two actors have threads that are<br>
    able to perform computation, which should be allowed to perform<br>
    computation? The only other obvious answer is ``as much as<br>
    possible''. This can be made determinate, but typical PN workflows<br>
    can execute forever if given the opportunity. Hence, this yields an<br>
    infinite execution. PN is sufficiently expressive that determining<br>
    whether this execution is infinite is equivalent to solving the<br>
    famous halting problem in computation, and hence is undecidable.<br>
    This property of PN explains why it is challenging to introduce a<br>
    model of time to PN. Specifically, timed variants of PN that have<br>
    appeared in the literature allow time to advance when the model<br>
    deadlocks. But whether the model deadlocks is undecidable, and<br>
    typical models never deadlock. Thus, the loosest abstract semantics<br>
    comes at a serious price, an inability to introduce a model of time.<br>
    For example, the workflow of Fig. 1 with PN on the outside<br>
    would be hard to reuse inside others. It follows that, when a<br>
    workflow has potential to be reused inside others, PN should be<br>
    avoided and, if possible, replaced by a more reusable director.<br>
    Moreover, models that require time to advance cannot be used<br>
    within PN.<br>
    <br>
    --end--<br>
    <br>
    It looks like the link to Antoon's website that provides further
    information is broken.<br>
    I've sent him email to see if we can get the link fixed.  In the
    meantime, there is<br>
    <br>
<a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/domainCompatibility.htm">http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/domainCompatibility.htm</a><br>
    <br>
    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.<br>
    <br>
    I opened your models, exported the xml and stripped out the Kepler
    specific code so that Ptolemy users can open them.  <br>
    <br>
    See below for some other comments.<br>
    <br>
    On 11/23/11 2:38 AM, Michal Owsiak wrote:
    <blockquote cite="mid:4ECCCD25.8020404@man.poznan.pl" type="cite">Hi,
      <br>
      <br>
      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.
      <br>
      <br>
      However, I have encountered some issues.
      <br>
      <br>
      First things first. If I understand this paper right:
      <br>
      <br>
      <a class="moz-txt-link-freetext" href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-139.pdf">http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-139.pdf</a>
      <br>
      <br>
      It should be possible to embed PN within PN (Table 1).
      <br>
      <br>
      However, if I try to do so I am getting errors.
      <br>
      <br>
      1. In case of "Will never start.kar" Kepler wraps up and nothing
      happens.
      <br>
      <br>
      2. In case of "012 - Simple - PN inside PN.kar" I am getting an
      exception.
      <br>
      <br>
      ptolemy.kernel.util.IllegalActionException: Receiver in the port:
      .Simple - PN inside PN.CompositeActor.output is not a consumer
      receiver
      <br>
      <br>
      3. In case of "013 - Simple - no domain inside PN.kar" everything
      is fine.
      <br>
      <br>
      Why there are such differences in embedding PN inside PN?
      <br>
      <br>
      Another question is. According to the paper:
      <br>
      <br>
      "To determine which combinations are possible, we need to know two
      things about a director:
      <br>
      1. What properties it assumes of the actors under its control, and
      <br>
      2. What properties it exports via the opaque composite actor in
      which it is placed.
      <br>
      If a director’s exported properties match those assumed by another
      director, then it can be used within that other director"
      <br>
      <br>
      Is there any way of checking mentioned properties automatically?
      <br>
    </blockquote>
    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
    <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/ptolemyII/designdoc.htm">http://ptolemy.eecs.berkeley.edu/ptolemyII/designdoc.htm</a><br>
    <blockquote cite="mid:4ECCCD25.8020404@man.poznan.pl" type="cite">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.
      <br>
    </blockquote>
    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.<br>
    <blockquote cite="mid:4ECCCD25.8020404@man.poznan.pl" type="cite">
      <br>
      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?
      <br>
    </blockquote>
    I don't think it is possible, but perhaps someone can correct me.<br>
    <br>
    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.<br>
    <br>
    _Christopher<br>
    <blockquote cite="mid:4ECCCD25.8020404@man.poznan.pl" type="cite">
      <br>
      Thanks in advance for your support.
      <br>
      <br>
      Regards
      <br>
      <br>
      Michal Owsiak
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kepler-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kepler-users@kepler-project.org">Kepler-users@kepler-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
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 </pre>
  </body>
</html>