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]
