MultiInstanceComposite
ptolemy.actor.lib.hoc.MultiInstanceComposite

A <a href="../../../../ptolemy/actor/TypedCompositeActor.html">ptolemy.actor.TypedCompositeActor</a> that creates multiple instances of itself during the preinitialize phase of model execution.<p> A MultiInstanceComposite actor may be used to instantiate <a href="../../../../ptolemy/actor/lib/hoc/MultiInstanceComposite.xml#nInstances">nInstances</a> identical processing blocks within a model. This actor (the "master") creates <a href="../../../../ptolemy/actor/lib/hoc/MultiInstanceComposite.xml#nInstances">nInstances</a>&nbsp;-&nbsp;1 additional instances (clones) of itself during the <a href="../../../../ptolemy/actor/lib/hoc/MultiInstanceComposite.html#preinitialize">preinitialize()</a> phase of model execution and destroys these additional instances during model <a href="../../../../ptolemy/actor/lib/hoc/MultiInstanceComposite.html#wrapup">wrapup()</a>. MultiInstanceComposite <em>must be opaque</em> (have a director), so that its Actor interface methods (preinitialize(), ..., wrapup()) are invoked during model initialization. Each instance may refer to its <a href="../../../../ptolemy/actor/lib/hoc/MultiInstanceComposite.xml#instance">instance</a> [0..<a href="../../../../ptolemy/actor/lib/hoc/MultiInstanceComposite.xml#nInstances">nInstances</a>-1] parameter which is set automatically by the master if it needs to know its instance number.<p> MultiInstanceComposite <em>input</em> ports must not be multiports (for now) and may be connected to multiports or regular ports. During preinitialize(), the master MultiInstanceComposite determines how its input ports are connected, and creates additional relations in its container (the model it is embedded in) to connect the input ports of its clones (instances) to the same output port if that port is a multiport. If that output port is a regular port, the clone's input port is linked to the already existing relation between that output port and the master's input port. MultiInstanceComposite <em>output</em> ports must not be multiports (for now) and must be connected to input multiports. The master MultiInstanceComposite creates additional relations to connect the output ports of its clones to the input port. Finally, after all these connections are made, the master's preinitialize() calls preinitialize() of the clones.<p> From here on until wrapup(), nothing special happens. Type resolution occurs on all instances in the modified model, so does initialize() and the computation of schedules by directors of the master and clones.<p> During model wrapup(), the master MultiContextComposite deletes any relations created, unlinks any ports if needed, and deletes the clones it created. To re-synchronize vergil's model graph, an empty ChangeRequest is also queued with the Manager.<p> Actor parameters inside MultiInstanceComposite may refer to parameters of the container model. This presents a problem during cloning() and wrapup() where the container model's parameters are not in scope during the clone's validateSettables() (unless the MultiInstanceComposite is built as a moml class having its own set of parameters). This problem is for now solved by providing a temporary scope copy using a ScopeExtendingAttribute for the cloning() and wrapup() phases of the clones.<p>

Author(s): Zoltan Kemenczy, Sean Simmons, Research In Motion Limited
Version:$Id: MultiInstanceComposite.doc.html,v 1.1 2006/02/22 18:41:22 mangal Exp $
Pt.Proposed Rating:Red (zkemenczy)
Pt.Accepted Rating:Red (cxh)




nInstances
The total number of instances to instantiate including instance 0 (the master copy).
instance
The index of this instance.