LevelCrossingDetectorDetectsGlitches output changed between 6.0.2 and 7.0.1

[cxbrooks]

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#296 From: @cxbrooks Reported version: 8.1.devel CC: pt-dev@chess.eecs.berkeley.edu

[cxbrooks]

Created attachment 30 JPG version of a PowerPoint slide that shows old behavior

On 4/25/09, Edward wrote:

The demo LevelCrossingDetectorDetectsGlitches is behaving strangely. The output plot labeled Piecewise Continuous Signal is not showing all the output values at time 1.5 (these should include the value -1.0). However, the level-crossing detectors are correctly detecting these values!

I'm mystified. Any easy way to check when this started happening?

Attached is a jpg version of a PowerPoint slide that shows the old behavior.

The demo does work as expected in Ptolemy II 6.0.2, which was released on 2/4/2007

The failure is present in a Ptolemy tree from 4/1/2007

The failure is present in Ptolemy II 7.0.1

However, the Continuous domain version of this demo in 8.1.devel works as expected.

To track this down would require working through various versions of the ptII tree. I'm concerned that even if we find the right revision of the change that caused the problem, then folding in that change could be difficult.

An alternative would be to remove the ct version of this demo from the release.

This problem points out the need to have tests for the demos.

Attached file: LevelCrossingDetectorDetectsGlitches.jpg (image/jpeg, 138355 bytes) Description: JPG version of a PowerPoint slide that shows old behavior

[cxbrooks]

Edward wrote:

I think removing the CT version of this demo is the way to go. It works in the continuous domain...

I tracked this down to this change:

2007-02-11 18:52 hyzheng

* [r45276] /trunk/ptolemy/domains/fsm/kernel/FSMDirector.java:
  removed unnecessary code in two places:
  1. prefire() -- since the receivers are mail boxes with only one
  capacity and supporting overwriting, there is no need to clean up
  the content at the prefire() method. And even we need so, the
  clean up should be put into the postfire() method.
  2. transferInputs(IOPort) -- before putting new tokens, old
  tokens are removed. This is unnecessary since the receiver
  supports overwriting.

The diff is: bash-3.2$ svn diff -r 45275:45276 ptolemy/domains/fsm/kernel/FSMDirector.java Index: ptolemy/domains/fsm/kernel/FSMDirector.java

--- ptolemy/domains/fsm/kernel/FSMDirector.java (revision 45275) +++ ptolemy/domains/fsm/kernel/FSMDirector.java (revision 45276) @ @ -630,37 +630,6 @ @ if (_debugging) { _debug("Prefire called at time: " + getModelTime()); }

• // Clear the inside receivers of all output ports of the container.
• // FIXME: why here? should this happen at the postfire() method?
• CompositeActor actor = (CompositeActor) getContainer();
• Iterator outputPorts = actor.outputPortList().iterator();
• while (outputPorts.hasNext()) {
• IOPort p = (IOPort) outputPorts.next();
• Receiver[][] insideReceivers = p.getInsideReceivers();
• if (insideReceivers == null) {
• continue;
• }
• for (int i = 0; i < insideReceivers.length; i++) {
• if (insideReceivers[i] == null) {
• continue;
• }
• for (int j = 0; j < insideReceivers[i].length; j++) {
• try {
• if (insideReceivers[i][j].hasToken()) {
• insideReceivers[i][j].get();
• }
• } catch (NoTokenException ex) {
• throw new InternalErrorException(this, ex, null);
• }
• }
• }
• }

•  // Set the current time based on the enclosing class.
   super.prefire();
   return getController().prefire();

  @ @ -730,12 +699,7 @ @ if ((insideReceivers != null) && (insideReceivers[i] != null)) { for (int j = 0; j < insideReceivers[i].length; j++) {

• if (insideReceivers[i][j].hasToken()) {
• insideReceivers[i][j].get();
• }

•                      insideReceivers[i][j].put(t);

•                      if (_debugging) {
                           _debug(getFullName(),
                                   "transferring input from "

Folding that change back into FSMDirector.java seems to make the model work. I'm working on creating a test case that illustrates the problem and on running the tests with this change in place.