Dear Erwin:
Your comments, feedback, and suggestions are most welcome, and I
wish I had a clean solution for you. But we do not view this issue
as "an important internal concept for the Ptolemy designers." It is,
in fact, a feature intended for end users, not an internal concept.
Consider the Distributor actor. It has a single port input and a
multiport output. The output can be connected to any number of destinations.
What this actor does is to send the first input token it receives to the
first output channel, the second token it receives to the second
output channel,
etc. I.e., it splits a stream of tokens into a parallel set of streams.
This is useful for many purposes, including for example achieving parallel
computation in a process network.
If multiple connections to a port were to mean broadcast, this actor
would not be possible.
Instead, we would have to design a distributor with two output ports,
and another with three, and another with four, etc. Or we would have to
grow the number of ports dynamically (which IMHO would be awkward).
Moreover, with this design, if the number of output channels is large,
the graphical notation will become very awkward. Moreover, there would
be no way to make the number of output channels a parameter of the model.
There are quite a few actors like this. Switch and Select are also
examples. A demo that makes use of the features and shows have
convenient they can be is at
$PTII/ptolemy/actor/lib/hoc/demo/HocDE/HocDE.xml
which was created by Zoltan Kemenczy of Research in Motion (RIM)
(makes of the Blackberry handheld).
So we are open to suggestions for a better visual syntax, but not
one that discards the ability to connect multiple channels to a port.
This would be a serious loss of functionality for the end user.
BTW: from your comments, you must not be running the latest version
of Ptolemy II (?). The latest version does visually indicate channel
ordering at a multiport.
Edward
At 02:01 AM 2/22/2006, Erwin De Ley wrote:
Hi again,
OK, let me first explain a bit what we're trying to achieve (cfr
http://www.isencia.be/solutions/solutions.html, the Passerelle story).
1. We're not in computer science, we're a small IT services group
2. We want a clear split in roles and competences between
component/actor developers and application assemblers/modelers.
Each should have an own set of abstractions, and e.g. a modeler
should not be forced to know about internal implementation details
of an actor he/she's using.
3. The application components/actors have some internal behaviour
4. They communicate with other components via ports that each have a
single clearly defined function
5. For our purposes, most ports are indeed either single or
broadcast ports. And this is certainly the case from the modeler perspective.
Based on an initial evaluation back in 2001, we selected Ptolemy as
an important base component for our Passerelle story.
(in fact I think Ptolemy has very wide usage possibilities, and it's
a shame it is not more popular in the developer community)
I see from the reactions that this multi-channel thing seems to be
an important internal concept for the Ptolemy designers.
However, there is a discrepancy between what an actor developer can
achieve with this, and what the Vergil user is confronted with.
(which is a problem for our goal 2)
The multi-channel features of Ptolemy allow an actor developer to
address a channel by an index.
On the other hand, the person drawing the model in Vergil has no
concept of channel index available (as far as I know at least).
It seems that it's just the order in which you draw connections from
the output port, that determines the index.
(which is a bit tricky, certainly if the modeler starts editing an
existing model)
So there is some mismatch between what's feasible inside an actor,
and the abstractions that a modeler sees in the UI.
As a consequence, it is difficult for the modeler to build a correct model...
Point 3 of our goals is a bit at odds with the fact that you could
have actors that use channel subsets (of the same multiport) for
different purposes, which seems to be a feature Ptolemy wants to support...
If we need to differentiate channels, we put them on different
ports, as a port is clearly distinguishable from a modeler's
perspective, and the purpose can be reflected in the port name.
There are a limited nr of applications for fan-out ports,
round-robin load-balancing etc that do really use the
channel-per-channel addressing.
But these are the exceptions, and we'll probably encapsulate these 2
cases somehow (in relation sub-types?) to avoid coupling the actor's
behaviour to the messaging paradigm used.
I've checked the Kepler project a bit as well, which also has a user
base that are not computer scientists, and some more samples in
Ptolemy itself (e.g. sine actor etc).
And it seems Kepler and Ptolemy are generally using single ports for
output, whereas we're generally using multiports (and our actors
always broadcast on them).
So maybe the quickest fix, is to just prohibit multiport outputs on
our composites, so modelers are always forced to use the relation
diamonds if they need multiple connections...
Anyway, if the current behaviour is what the Ptolemy team wants, of
course no need to change it. We'll try to find the best way to
override it for our purposes.
Kind regards
Erwin
Edward A. Lee wrote:
However, if you did in fact simplify connections to always be
a broadcast, then you would lose significant expressiveness.
The idea of a multiport is to be able to specify a variable
number of distinct channels without having to create a variable
number of distinct ports (which could get very awkward if the
number is large).
So how would you make a distinction between a broadcast connection
and multi-channel connection?
Edward
At 08:32 AM 2/21/2006, Erwin De Ley wrote:
Thank you for this explanation.
Unfortunately, the users in our case are not computer scientists,
and it is indeed confusing for them.
(and I must admit that this seems also not the most intuitive for
myself as well ;-) )
As far as they are concerned, the relations (diamonds) are just
nice to have around to clean up the routing a bit when needed...
For them, a connection is a connection and a white port is a
multiport (and a black port is a single-connection port) and
channel widths are not in their mindset at all.
And a multiport with multiple outgoing channels/relations/links is
connected to all actors on the other side of these channels/relations/links...
I think I will need to override the current Ptolemy behaviour to
have a user-friendly modeler experience.
And it would seem that somewhere in the port.broadcast() call
sequence an extra constraint is implemented to limit the number of
returned receivers.
Is this correct? Then I would need to remove that constraint and
return all remote receivers that are visible through the
IORelation.deepReceivers().
During debugging I was not able to really pinpoint the spot where
this constraint is implemented.
So if someone has a pointer to help me out, I would really appreciate it!
Thanks!
Erwin
Edward A. Lee wrote:
At 08:44 AM 2/20/2006, Erwin De Ley wrote:
Hi,
We're using and extending Ptolemy 4.0.1 for dataflow processing
and generic pipe-and-filter application architectures.
There seems to be an issue when using multiport output ports on
a Composite Actor!?
I've attached a simple model with a Const actor sending
something to a Composite Actor.
This one has one input port directly connected to its single
output port, which is a multiport.
<snip>
A bug in the receiver management when Composite Actors are present?
No, this isn't a bug, though I admit that this functionality
is a potentially confusing feature of Ptolemy II.
In your model, there is only one channel into the composite
actor, so given that it just routes its inputs to its outputs,
there is no source of data for a second channel. The model below
has a second channel passing through the composite. Note that
in this model I had to set the width of the connection on the
inside to 2 (or to 0, which results in the width being inferred
from the environment).
If what you intended was for the one channel to be routed
to both display actors, then the right connection uses a relation
to fork the channel to the two display actors.
This is discussed on p. 55 (I think) in chapter 2 of the users
manual.
Edward
<?xml version="1.0" standalone="no"?>
<!DOCTYPE entity PUBLIC "-//UC Berkeley//DTD MoML 1//EN"
"http://ptolemy.eecs.berkeley.edu/xml/dtd/MoML_1.dtd";>
<entity name="test-composite-and-multiport"
class="ptolemy.actor.TypedCompositeActor">
<property name="_createdBy"
class="ptolemy.kernel.attributes.VersionAttribute" value="6.0-devel">
</property>
<property name="SDF Director"
class="ptolemy.domains.sdf.kernel.SDFDirector">
<property name="iterations"
class="ptolemy.data.expr.Parameter" value="2">
</property>
<property name="_location"
class="ptolemy.kernel.util.Location" value="{125, 70}">
</property>
</property>
<property name="_windowProperties"
class="ptolemy.actor.gui.WindowPropertiesAttribute"
value="{bounds={232, 253, 815, 652}, maximized=false}">
</property>
<property name="_vergilSize"
class="ptolemy.actor.gui.SizeAttribute" value="[600, 534]">
</property>
<property name="_vergilZoomFactor"
class="ptolemy.data.expr.ExpertParameter" value="1.0">
</property>
<property name="_vergilCenter"
class="ptolemy.data.expr.ExpertParameter" value="{300.0, 267.0}">
</property>
<entity name="Const" class="ptolemy.actor.lib.Const">
<doc>Create a constant sequence</doc>
<property name="_icon" class="ptolemy.vergil.icon.BoxedValueIcon">
<property name="attributeName"
class="ptolemy.kernel.util.StringAttribute" value="value">
</property>
<property name="displayWidth"
class="ptolemy.data.expr.Parameter" value="60">
</property>
</property>
<property name="_location"
class="ptolemy.kernel.util.Location" value="[90.0, 190.0]">
</property>
</entity>
<entity name="Display" class="ptolemy.actor.lib.gui.Display">
<property name="_windowProperties"
class="ptolemy.actor.gui.WindowPropertiesAttribute"
value="{bounds={766, 300, 330, 237}, maximized=false}">
</property>
<property name="_location"
class="ptolemy.kernel.util.Location" value="{405, 135}">
</property>
</entity>
<entity name="Display2" class="ptolemy.actor.lib.gui.Display">
<property name="_windowProperties"
class="ptolemy.actor.gui.WindowPropertiesAttribute"
value="{bounds={694, 57, 330, 237}, maximized=false}">
</property>
<property name="_location"
class="ptolemy.kernel.util.Location" value="{395, 270}">
</property>
</entity>
<entity name="CompositeActor"
class="ptolemy.actor.TypedCompositeActor">
<property name="_location"
class="ptolemy.kernel.util.Location" value="[230.0, 195.0]">
</property>
<port name="port" class="ptolemy.actor.TypedIOPort">
<property name="output"/>
<property name="multiport"/>
<property name="_location"
class="ptolemy.kernel.util.Location" value="[380.0, 210.0]">
</property>
</port>
<port name="port2" class="ptolemy.actor.TypedIOPort">
<property name="input"/>
<property name="multiport"/>
<property name="_location"
class="ptolemy.kernel.util.Location" value="[230.0, 200.0]">
</property>
</port>
<relation name="relation" class="ptolemy.actor.TypedIORelation">
<property name="width"
class="ptolemy.data.expr.Parameter" value="0">
</property>
</relation>
<link port="port" relation="relation"/>
<link port="port2" relation="relation"/>
</entity>
<entity name="Const2" class="ptolemy.actor.lib.Const">
<property name="value"
class="ptolemy.data.expr.Parameter" value="2">
</property>
<doc>Create a constant sequence</doc>
<property name="_icon" class="ptolemy.vergil.icon.BoxedValueIcon">
<property name="attributeName"
class="ptolemy.kernel.util.StringAttribute" value="value">
</property>
<property name="displayWidth"
class="ptolemy.data.expr.Parameter" value="60">
</property>
</property>
<property name="_location"
class="ptolemy.kernel.util.Location" value="[90.0, 255.0]">
</property>
</entity>
<relation name="relation" class="ptolemy.actor.TypedIORelation">
</relation>
<relation name="relation2" class="ptolemy.actor.TypedIORelation">
</relation>
<relation name="relation3" class="ptolemy.actor.TypedIORelation">
</relation>
<relation name="relation4" class="ptolemy.actor.TypedIORelation">
<property name="width"
class="ptolemy.data.expr.Parameter" value="1">
</property>
</relation>
<link port="Const.output" relation="relation"/>
<link port="Display.input" relation="relation2"/>
<link port="Display2.input" relation="relation3"/>
<link port="CompositeActor.port" relation="relation2"/>
<link port="CompositeActor.port" relation="relation3"/>
<link port="CompositeActor.port2" relation="relation"/>
<link port="CompositeActor.port2" relation="relation4"/>
<link port="Const2.output" relation="relation4"/>
</entity>
------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal
------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal
------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
[EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
