[kepler-dev] MultiInstanceComposite - two issues
Christopher Brooks
cxh at eecs.berkeley.edu
Tue May 8 07:45:50 PDT 2012
Hi Michal,
The MultiIinstance.kar works for me in the Kepler trunk.
The version of the MultiInstance.kar that you sent produces two outputs
on the Display.
If I move the Display to the inside of the MultiInstanceComposite, then
I get just one line, which seems odd.
What version of Kepler are you using?
Yes, there are assumptions about the inner model, see the documentation
or MultiInstanceComposite, reproduced below:
>
> A composite actor that creates multiple instances of itself during the
> preinitialize phase of model execution. A MultiInstanceComposite actor
> may be used to instantiate /nInstances/ identical processing blocks
> within a model. This actor (the "master") creates /nInstances/ - 1
> additional instances (clones) of itself during the /preinitialize()/
> phase of model execution and destroys these instances during model
> /wrapup()/. MultiInstanceComposite *must contain a director*, so that
> its Actor interface methods (/preinitialize(), ..., wrapup()/) are
> invoked during model initialization. Each instance may refer to its
> /instance/ [0../nInstances/-1] parameter, which is set automatically
> by the master if it needs to know its instance number.
>
> MultiInstanceComposite input ports must not be multiports 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 output ports must not be
> multiports 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. 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. During
> model /wrapup()/, the master MultiInstanceComposite 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.
>
_Christopher
On 5/8/12 1:05 AM, Michal Owsiak wrote:
> Hello Kepler team,
>
> I have two issues with Multi Instance Composite actor.
>
> What I am trying to achieve is embedding DDF workflow within PN
> workflow where internal composite actor (driven by DDF) is started in
> N multiple instances.
>
> The workflow I am trying to embed is attached as SimpleLoop.kar
>
> The workflow I am trying to build is attached as MultiInstance.kar
>
> It looks pretty straightforward to build this workflow, however I have
> two issues:
>
> 1. When I build MultiInstance workflow from the scratch it doesn't
> work at all.
>
> I have to close Kepler and reopen it to get workflow started.
>
> 2. Second issue is that workflow doesn't work properly if I put
> Display actor inside. There are issues while instantiating components.
>
> You can validate this issue by opening MultipleInstance.kar and
> putting Display actor somewhere inside Composite actor (connect it to
> any relation inside).
>
> I have two questions regarding Multi Instance Composition.
>
> Question 1: do I have to make some assumptions regarding sub workflow
> when it comes to embedding workflow within Multi Instance Composite?
>
> Question 2: is it possible to use Display actor within Multi Instance
> Composite. Is there any workaround?
>
> Thanks in advance for the support
>
> Cheers
>
> Michal
>
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20120508/2f3c27ab/attachment.html>
More information about the Kepler-dev
mailing list