CADSWES Maintenance Accomplishment Report Compilation -- March 2014 -- edit 4-15-2014
The report includes:
(II) RiverWare Software Maintenance
|
The following RiverWare 6.4 patch was made. Release notes are included:
RiverWare 6.4.7 was released on March 19, 2014.
Distributed MRM
|
The following bugs were fixed:
*details for three particular bugs are provided below.
Bug 5468 Detail: If RIVERWARE_HOME isn't set distributed MRM generates bad XML
RiverWare writes the RIVERWARE_HOME environment variable to the XML file which defines a distributed multiple run:
<env>RIVERWARE_HOME_464=C:/Program Files/CADSWES/RiverWare 6.4.6</env>
However, if RIVERWARE_HOME isn’t set RiverWare wrote bad XML:
<env>=C:/Program Files/CADSWES/RiverWare 6.4.6</env>
This caused the distributed MRM controller’s starting RiverWare to fail with a cryptic "Cannot start" error message. The fix was to make the <env> element optional and only present when RIVERWARE_HOME is set. (The environment variable is probably unnecessary now that distributed multiple runs are constrained to one computer. It was previously necessary because there was no guarantee RIVERWARE_HOME was set on other computers.)
Bug 5469 Detail: Distributed MRM generates bad XML if Global Function Set is saved in model file
RiverWare writes the currently open global functions sets to the XML file which defines a distributed multiple run; if the global function set was saved in the model file RiverWare wrote:
<gfs>Global Function Set 1 (from model file)</gfs>
The distributed MRM controller translated this to a batch mode command which attempted to open the file "Global Function Set 1 (from model file)" which not surprisingly failed. The fix is to make the <gfs> element optional and only present when the global function set is in an external file.
Bug 5472 Detail: MRM distributed run working directory specification cannot use environment variable
The distributed MRM configuration requires a working directory where working files associated with the distributed multiple run are written. The configuration didn’t allow environment variables in the directory path, for example:
$CRSS_DIR/temp
which was inconvenient for BOR, whose CRSS model is defined in terms of $CRSS_DIR. The directory path now allows environment variables.
HDB Server Removed / OracleConnect and HdbConnect Integrated into RiverWare:
With the port to Qt4, RiverWare and server code had to be rewritten to use Qt4 socket classes. When the HDB server was modified and rebuilt to include HDB ensemble functionality, it was noted that “phantom” commands seemed to be intermittently reflected from the RiverWare client back to the server over the socket. With testing by Reclamation that involved moving a lot of data via the ensemble functionality, the server commands would get out of sync with the RiverWare client and the server would hang. It was strongly suspected that these phantom commands were causing the out of sync problem. To address this problem, the client/server mechanism was taken out of the communication process, and the code to connect to the HDB Oracle database was incorporated directly into RiverWare as described below.
The OracleConnect Visual Studio project that was in the HDB server was moved to the RiverWare Visual Studio Solution (this contains the Oracle C++ Call Interface code that connects to HDB for the OracleConnect and HdbConnect classes, as well as the OracleError class). The RwOracle and RwHdb classes in RiverWare were modified to contain a static instance of OracleConnect and HdbConnect, respectively, Functions in RwOracle and RwHdb were modified to call the connect code directly through these static instances. Code was added to RwOracle and RwHdb classes to process Oracle error and warning messages returned from the connection code and add these messages to the DMI handler as well as posting them as RiverWare warnings. Diagnostic messages for illuminating the interactions with HDB were in the HdbClient and OracleClient classes under the diagnostic category of ClientServer. These were moved to the RwOracle and RwHdb classes under the category of Dmi Dataset.
Compilation of the new RiverWare code with Oracle libraries produced errors with type definitions of the word “boolean”. Investigation found that Oracle include files will typedef “boolean” as an int if it is not already defined. A windows library was later declaring it as a typedef of unsigned char creating the multiple definition error. The solution was to ensure that the Windows file wtypes.h is included before the Oracle file occi.h so that the Windows definition happens first and then Oracle does not attempt to define it.
A server timeout value could be set and saved with each HDB dataset that defined the amount of time before an error was declared if the RiverWare client did not hear back from the HDB server. This was needed for the situation where the communication link between client and server became inoperable. The HDB dataset dialog was modified to remove the widgets and handler code for setting the timeout values, as these are no longer needed with the new code arrangement. The RiverWare help was modified to delete description of the server timeout functionality.
A release build of the new code was tested to ensure that the HDB functionality works correctly. Input and output DMIs as well as input and output ensembles were run to exercise all of the methods that connect to HDB. The posting of diagnostics and error messaging were also tested to verify proper operation. A snapshot of the new executable will be sent to Reclamation at Loveland for user testing.
None reported for March 2014.
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. In March, the tests failed when the new HDB/oracle client work was implemented. The tests were analyzed and the testing machines were updated so the tests ran again.
None reported for March 2014.
---