[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