[kepler-dev] [Bug 3300] - CompositeActor does not support multiport

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3300


cxh at eecs.berkeley.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from cxh at eecs.berkeley.edu  2008-05-16 20:02 -------
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" <cxh at eecs.berkeley.edu>
To: "Edward A. Lee" <eal at eecs.berkeley.edu>
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