infinite loop resolving port width
There are several actors whose output port is set to multiport. When this port is connected to a multiport input port, an error occurs when the workflow executes saying that the default port width could not be determined. The error message says that one way to fix this is call setDefaultPortWidth(1). This works if the output port is connected to only one port, but if the output port is connected to more ports, an infinite loop occurs during preinitialize(). I'm attaching an example workflow.
#3 Updated by Christopher Brooks over 4 years ago
- % Done changed from 0 to 20
- File MultiportOutHangDuringGetWidth.xml MultiportOutHangDuringGetWidth.xml added
I can replicate this in Ptolemy, outside of Kepler.
It seems that the problem has to do with having more than one Display actor connected to a multiport output.
The attached model (MultiportOutHangDuringGetWidth.xml) replicates the problem using the Minimum actor, which has a multiport output connected to two Display actors.
The model hangs in preinitialize():
However, $PTII/ptolemy/actor/lib/test/auto/MinimumMultiports.xml does not hang.
It has the Minimum actor connected to Test actors instead of Display.
I tried reverse type inference on my test case, but that did not change anything.
I'll see if I can get Edward's input.
#4 Updated by Christopher Brooks about 4 years ago
- % Done changed from 20 to 90
- Assignee changed from Christopher Brooks to Daniel Crawl
I checked a copy of MultiportOutHangDuringGetWidth.xml in to $PTII/ptolemy/actor
I think this is fixed.
I'm redispatching to Dan.
"I found a logic error in the width inference algorithm and have checked in a fix."
"Note that nevertheless one should not be making output ports multiports to accomplish broadcast."
"The ones in the Ptolemy tree that do this are legacy. E.g., Maximum.java says:"
/* Note that the output ports need not be multiports since all output * channels carry the same data. Using multiports this way is not * recommended, so please do not emulate this design in your own actors. * Changing this actor to the recommended design would break existing * models, so we leave it as is.
"Instead of making output ports multiports, model builders should create a relation and fork the output from there."