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
[email protected]
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

_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

Reply via email to