CADSWES Maintenance Accomplishment Report Compilation -- May 2014
Edit: 6-4-2014 (Phil)

(II) RiverWare Software Maintenance

  1. Releases, Patches and Snapshots
  2. Software Updates, Bug fixes (not associated with new development)
  3. Development tool improvements; issue tracking software; modelcomp
  4. Enhancements or changes to regression tests (not part of development tasks)
  5. Download, Install and Release Processes
  6. Updates to license software/procedures
  7. Updates to download/install/configure user documentation
  8. Modification to Web pages for downloads and installs

(II.A) Releases, Patches and Snapshots

The following releases were generated this month:

RiverWare 6.4.8 was released on May 2, 2014 with the following release notes:

Bugs 
The following bugs were fixed:

  • 5465: In a Series Slot dialog with a large number of timesteps, changing the timestep size could lead to a crash.
  • 5471: Diagnostic settings for predefined functions were not working in some circumstances.
  • 5473: A RPL set with a large number of statements would not load.
  • 5474: A model report for a three column table slot gave incorrect labels.
  • 5477: A crash could occur when changing the run range with the Edit Account dialogs open.
  • 5482: The slot Top of Conservation Pool is assumed to be the same across a flood control subbasin. This is now correctly enforced.
  • 5484: A model aborted the first run because certain predefined functions were called before setup verification methods were executed.
  • 5485: An incorrect error was issued that turbine release was greater than capacity. This was fixed by improving the convergence algorithm for the solveMB_GivenInflowRelease dispatch method on the Level Power Reservoir.
 

RiverWare 6.4.9 was released on May 14, 2014 with the following release notes:

Bugs 
The following bug was fixed:

  • 5486: Changing the run dates in an accounting model under certain conditions caused RiverWare to fail.

(II.B) Software Updates, Bug fixes (not associated with new development)

The following bugs were analyzed and closed without changes:

The following bugs were fixed:

*details for these bugs are provided below.
**enhancements described elsewhere in the May 2014 Accomplishments Report were made in the course of addressing this bug.

Bug 809 Detail -- RiverWare name changes:

Approximately 300 category and method names were modified to adhere to a standard format. This included formatting all names in title case, including spaces between all words, removing terms such as category, calculation or calc from the names and in some cases making the name more descriptive of what the method does. These changes will be available in RiverWare 6.5.

Bug 4247 Detail -- Closing the console window on Windows OS crashes RiverWare

Now only in very special circumstances does text sent to the RiverWare process' output streams ("standard error" and "standard out") cause a terminal window to be shown. (One particular circumstance is lack of a valid RiverWare license). This used to happen when unusual errors were detected in RiverWare or in Qt. These output streams are still useful in testing and debugging RiverWare -- they can be redirected to a file or to a console window by invoking RiverWare with one of these command line parameters:

--log <log file path>
--log console

Bug 5405 Detail -- Diagnostics Output Window: Performance Problems, Freezing

The Gnats 5405 bug model helped us identify and address two related performance problems with the Diagnostics Output Window handling a very large number of messages (e.g. > 100,000). With this model, a 35 second run took over an hour to complete when informational diagnostics were enabled. In one case, the GUI was frozen for most of that time.

The sources of the slow execution and "frozen" (unresponsive) user interface have been substantially addressed. Now, generating many "informational" diagnostics messages slows down the run only by a small amount -- in particular when the Diagnostics Output Window is closed during the run.

This document provides background, analysis, and descriptions of changes and performance results:

Note: This document has yet to be updated with subsequent design decisions. We decided against disabling the window's "Minimize" function. The Diagnostics Output Window can be minimized, but doing so does not have the same performance benefit as closing the window. Also, in a debug build, closing (not minimizing) the window is necessary to avoid an extremely slow execution state which can occur. (With the implemented enhancements, we have not seen this problem in normal release builds).

Also, the current draft of that document does not mention the addition of a new "progress" dialog with an "Abort" button for message filtering operations. This popup dialog is now shown when a message filter operation is going to take over four seconds -- determined during the first second of filter execution.

(II.C) Development tool improvements; issue tracking software; modelcomp

Troubleshooting Visual Studio 2010 performance analysis tool

The Visual Studio 2010 performance analysis tool required an updated driver, but when the new driver was installed, the tool would abort analysis with an unhelpful error message. The problem was eventually resolved by uninstalling Symantec Endpoint Protection and replacing it with an alternative application to provide a firewall and other security measures.

Problem Resolved: Excel Add-Ins Tab Not Visible:

In setting up tests for the GPAT plugin in RiverSMART, it was discovered that the Add-Ins tab in Excel from which GPAT is initiated was hidden on a developer’s machine. There was no way to execute GPAT from the Excel interface. After research it was discovered that Visual Studio Tools for Excel, which is a COM Excel add-in, apparently keeps the Add-In tab from being visible when it is installed. When this Visual Studio Tools add-in was removed from Excel under the administrator account, this fixed the problem.

(II.D) Enhancements or changes to regression tests (not part of development tasks)

The regression tests continue to be maintained on a daily basis. This involves updating the regression tests to exercise new developments in the code. Also, as new code is added to the development area, the model comparisons performed in the nightly regression tests usually show differences (for example, because a new method category may have been added). When this occurs, the regression tests need to be updated to reflect the current state of the development area so model comparisons do not fail. In addition, every week, the daily history of each regression test is analyzed to determine if the run time or model size has significantly changed because of new development.

(II.E) Download, Install and Release Processes

(II.F) Updates to license software/procedures

(II.G) Updates to download/install/configure user documentation

(II.H) Modification to Web pages for downloads and installs

---