May 2014 Phil Bugs II for RW 6.5
Edit 6-03-2014 ... See also prior bug list.

Bugs II Status Summary / See Notes Below

New List Received: 5-14-2014

3612 CLOSED on 6-03 RPL Analysis Dialog does not update properly when a new rule assignment is added 2004 Steve
3718 Deferred Crash changing the timestep in the Run Control 2005 Kevin
4425 CLOSED on 5-19 Exporting an account sometimes loses input values 2008 Patrick
5284 CLOSED on 6-03 Workspace File->Reopen Model menu selection ignored 2013 Patrick
5399 Fixed 5-22 Cannot move rule to first position in policy group 2013 Steve
5405 Fixed 5-27 Diagnostics sometimes cause the RiverWare interface to freeze 2013 Patrick

Additional fixes applied during this time:

Gnats 3612: RPL Analysis Dialog does not update properly when a new rule assignment is added

In running by Patrick my solution to this bug (based on Brian's analysis), he preferred to handle this himself (in a very simple way -- just a quick thing). He was concerned that both: (1) a more "correct" way of fixing this is actually hard to do (information is not available where we need it) -- AND (2) some rearchitecture for the BPA project is going to make this moot. Patrick will either close the bug with an explanation, or address it in a simple way (possibly by just simplifying the assignment statement "name" so that it doesn't require dynamic updating). So, I'm handing this one off to Patrick.

[Patrick, 5-16-2014 e-mail to software group]:

Users cannot edit RPL statement names and can only view them by enabling their display in the RPL set/group editors or by enabling their display in the RPL set analysis dialog. All statements are given a default name upon creation, something like "Assign Statement" or "Print statement", but a few statement types also update their names at seemingly random times. For example, an assignment statement with a fully specified left-hand side might have a name like "ASSIGN TO Lake.Inflow". Bug 3612 points out that this name does not update as soon as the assign statement is edited, but only later.

As part of the BPA design, we plan on allowing users to edit the statement names, and at that time any automatic changing of the names would be problematic.

I propose that we stop dynamically changing statement names and close the bug. Statements would just retain their initial, relatively uninformative name. Any objections?

[Patrick, 6-03-2014 e-mail to software group]:

I closed bug 3612 without making any changes. I had planned to remove the dynamic updating of names, but then I discovered that we aren't currently saving the assign statements, so the current names would have changed and their would be no way to change them. Since this would be removing potentially useful information without providing a replacement, I decided that we should just wait until we add the ability to edit and save assignment statement names. The bug is minor (e.g., save/load corrects the problem) and old, so I don't think it is a problem go one more release before addressing it.

Gnats 3718: Crash changing the timestep in the Run Control

I have devised a fix for the first of two problems found, and improved a diagnostic method which detects the second.  We decided to hold off on further work on this bug until next week, possibly by a different team member. No changes have been checked in to the RiverWare trunk. See this Status webpage and "Bug3718" git branch:

Gnats 4425: Exporting an account sometimes loses input values

I am able to produce the behavior Patrick describes in this bug. What's happening makes sense (consistent with the explanation of the bug). We could, but it's not clear that we should force 'I' flags (from the linked Suppy slot) onto the Account Multislot when exporting the object. If BOTH objects (with their Accounts) on the two sides of the Supply are exported, the "I" flags apparent on the Account MultiSlot (really from the Supply) are preserved. So that's good.

At the 5-19-2014 software meeting, we decided to just close this bug. I closed it with this comment:

Gnats 4425 is being closed without changes.  The current behavior is a reasonable implication of the accounting system architecture.  When exporting a subset of the workspace, Input-flagged series values on account slots linked to a supply which is not part of the exported subset will lose those 'I' flags (because such series flags are actually on the supplies' series values).

Gnats 5284: Workspace File->Reopen Model menu selection ignored

We have "mitigated" this problem for this particular menu. Most mousing maneuvers avoid it. It's caused by a problematic solution (in Qt) to QTBUG-20094. That bug was closed, but reopened -- hopefully to be better addressed in future Qt releases. (A new person was assigned to manage this Qt bug just this week). I suggest we just hold tight and retest with future versions of Qt.

Update [6-03-2014]: We're deciding to close this bug. It's likely that whatever the Qt Project comes up with to address QTBUG-20094 in future releases will be sufficient.

Gnats 5399: Cannot move rule to first position in policy group

Currently, when dragging a Rule to the TOP of the list, this confirmation dialog box is shown:

This is how the current design is supposed to work: when dragging and dropping an item, the dragged item is placed AFTER the item on which it is dropped. I propose this: In the special case of dropping an item on the FIRST item, a different variation of the dialog will be shown. It will have three buttons -- something like this:

   [5-16-2014]

There are actually THREE move functions which need to be addressed:

See also Gnats 5490 Notes (5-16-2014):
 Canceling a move (drag) of the first Rule of a Policy Group puts it at the end of its original group

Gnats 5405: Diagnostics sometimes cause the RiverWare interface to freeze

The Gnats 5405 GUI freeze and profound slowness when generating diagnostics messages exhibited with the bug model have been addressed for RiverWare 6.5.  There are still inherent problems using the Qt4 item model/view classes for this application -- QTreeView isn't sufficiently "view-y" when dealing with a table model of over 200,000 rows.  At some point, we will probably want to reimplement the diagnostics output display lists without the Qt4 item model/view classes.

The model run is slower with the Diagnostics Output Window shown (as is expected) -- but only by a small multiple -- and less than double WHEN starting from an empty (cleared) diagnostics message list.  Now, closing the Diagnostics Output Window behaves well (doesn't freeze the GUI for minutes) and runs almost as fast as when Informational diagnostics are not generated.

It was found that minimizing the Diagnostics Output Window didn't have the performance benefit of closing the Diagnostics Output Window,  so the "minimize" controls have been disabled.  The user can now only close this window.  (Nothing gets lost by doing so).

THE ANALYSIS AND CHANGES FOR THESE FIXES are described in this document:

---