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