Re: [Ptolemy] Re: Transparent CompositeActor firings?

[Stephen Andrew Neuendorffer]

At 02:25 PM 6/16/2004, Christopher Hylands Brooks wrote:
The following appeared in comp.soft-sys.ptolemy.
If you respond, please cc [EMAIL PROTECTED]
-Christopher
------- Forwarded Message
From: Mark Hodson <[EMAIL PROTECTED]>
Subject: Transparent CompositeActor firings?
Date: Tue, 15 Jun 2004 00:05:18 +0930
G'day Ptolemy seers,
Despite having read the Ptolemy documentation more than once, I am
having trouble coming to grips with one particular aspect of Ptolemy's
execution model (I am mostly interested in the DE domain);
I wish to hierarchically compose a system, lets say for simplicity
entirely in the DE domain.  I thus wish a DE director to exist at the
top level, and every other part of the hierarchy below this to be
transparent, thus allowing that one director to resolve a correct
ordering for each iteration of the "world".  The benefit of transparency
here is of course that you get significant interleaving of firings of
the deepest (leaf) children as necessary.
eg. The world has two transponders, A and B.  Each transponder has an Rx
and a Tx.  The correct firing order is A.Tx with B.Tx before A.Rx and
B.Rx.  You needed A and B to be transparent to get this behaviour.
Given that in this scenario, A.Rx/A.Tx/B.Rx/B.Tx are the 4 AtomicActors,
and A and B are CompositeActors, my question is; do A and B get fired in
any way?  If not, why not, and if so, in accordance with what rules (wrt
the firing of their children, at least).
Only opaque actors are fired.  This includes all atomic actors and composite
actors with a director.  So, no, A and B will not get fired.

Of course if A and B have nothing to do, then there is no drama, but if
A and B carry some of the mathematics/behaviour of the model, then they
will require some sort of firing opportunity.
Then they should be opaque...  Note that in DE, a composite actor is perfectly
able to fire if only some of its inputs have events.  It will fire the 
correct contained
actors that receive those events and then return.


A case in point is the wiring of CompositeActor A's children, which
notionally I consider it responsible for.  There are many cases in
scientific computing when the first iteration of "bringing the models up
to time zero" has a different wiring to subsequent iterations.  I would
wish A to perform this rewiring duty at the conclusion of that first
iteration.  Other similar behaviours might include timed or triggered
introduction of additional children (perhaps A holds an input port that
is not connected to any child components, but rather is used as a
trigger to mutate the topology of A).
Can you give me some conceptual guidance on how you see this sort of
problem is best solved, in general terms and in the bounds of Ptolemy II?
Yes, these are certainly interesting questions...  We have recently begun
experimenting with some of these issues and some tentative first steps
are in the new 4.0 release.  We have variously been calling them "lifecycle"
actors or "higher-order" actors depending on the particular case.
Higher-order components tend to populate themselves during initialization, 
while
lifecycle actors tend to make more dynamic modifications during runtime.
I would take a look at these to see if you get some ideas...  Some of the key
difficulties are ensuring that the model is in a consistent state when 
making modifications
and ensuring that static analysis, which is sometimes necessary to ensure
semantics of a model, is performed again.

I would note that there is a distinct tradeoff between "complex, unchanging"
architectures and "simpler, changing" architectures...  It may be easier
to do a little bit more upfront work by explicilty representing the 
different control
flows in the model.

Steve
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]