Project

General

Profile

Actions

Bug #3300

closed

CompositeActor does not support multiport

Added by ben leinfelder almost 16 years ago. Updated almost 16 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
actors
Target version:
Start date:
05/16/2008
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
3300

Description

You can create a CompositeActor with input and output ports that are set as Multiports, but only the first value on the port is consumed.
Kevin ran into this when creating the river flow workflow for kruger.

Actions #1

Updated by Christopher Brooks almost 16 years ago

You need to explicitly set the width of the input link inside the composite.

See below.

I've opened a RFE in Ptolemy
https://chess.eecs.berkeley.edu/bugzilla/show_bug.cgi?id=164
I've also added to the Ptolemy II faq about this:
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm#multiportComposites

I'm closing this because it is not a bug, it is a feature,
though there is a RFE. It could be considered a doc bug or something.
It is a tad buggy that the 2nd input is dropped though.
Feel free to reopen it, though this is not a Kepler bug, it is a Ptolemy RFE.

From: "Christopher Brooks" <>
To: "Edward A. Lee" <>
Sent: Friday, November 30, 2007 9:48 AM
Subject: Re: [Ptolemy] 1+1 != 2 with transparent composite with multiport

Thanks!

In the perfect world, we would warn the user about dropping the second
channel.
What's odd is that both Consts fire and the data from the second Const
disappears. This is counterintuitive.

_Christopher
--------

This isn't a bug, it's a feature! ;-)

Seriously, what's going on here is that the "width" of the inside
relation is set (by default) to 1. In our semantics, when a multiport
has width 2 on the outside and width 1 on the inside, the second
channel
is dropped.

To get this to work, set the width of the relation on the inside to 0,
which means "infer the width from the connections".

Arguably, the default width should always be 0, but we would need a
proof of soundness. I.e., that the inferred width is always unique.
One of my students took a stab at such a proof a few years ago, but
didn't get anywhere. Probably worth revisiting...

Edward

At 08:14 AM 11/30/2007, Christopher Brooks wrote:

Jason writes:

Chris, is the way the attached works the intended implementation?
I thought the display would read 2.

Hi Jason,

Yep, 1+1 is usually 2, expect for sufficiently large values of 1.
:-)

The model you sent appears to illustrate a bug.

I checked in a test version as
ptolemy/domains/sdf/test/auto/SDFMultiportComposite.xml

The model is an SDF model that has two Consts connected to
a composite actor that has a multiport.

SDF
------- | |
Const ------->|Comp.| | | |
Const-----| -------

The composite is transparent (it has no internal director)
Inside the composite, the multiport is connected to the
plus port of an AddSubtract. The output of the
AddSubtract is connected to a Display:

---------- -----------

--------| + | | |

| Add/Sub|-->| Display | | - | | |
---------- -----------

When I run the test, the Display gets "1".
The version I checked in uses a Test actor which expects "2".

This test fails in Ptolemy II 4.0, 5.0 and 6.0.

I vaguely remember seeing a problem like this before.

Adding a SDF director to the composite does not help.

If the multiport is removed and two non-multiports are used, then
the test passes.

Any comments? This seems like it should work.

_Christopher

Actions #2

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 3300

Actions

Also available in: Atom PDF