A <a href="../../../../ptolemy/actor/TypedCompositeActor.xml">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> - 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>
Zoltan Kemenczy, Sean Simmons, Research In Motion Limited
$Id: MultiInstanceComposite.java 70402 2014-10-23 00:52:20Z cxh $
Ptolemy II 4.0
Red (zkemenczy)
Red (cxh)
The total number of instances to instantiate including instance
0 (the master copy).
The index of this instance.
If true, show the clones.