CADSWES Maintenance Accomplishment Report Compilation -- June 2017
Phil Weinstein, edit 7-14-2017 (a)
June 2017 Maintenance Highlights:
Report contributors:
(II) RiverWare Software Maintenance
|
The following releases were generated this month:
RiverWare 7.0.8 (6-02-2017) Release Notes:
Bug Fixes -- the following three issues were addressed:
|
RiverWare 7.1 Prereleases (6-20-2017 and 6-27-2017):
The RiverWare 7.1 Prerelease was sent to all users on 6-20-2017. A second Prerelease was shared with a more limited audience to confirm subsequent fixes, on 6-27-2017. This involved writing release notes, regenerating the help PDFs, updating the builds areas, creating the release executable, updating the website, and sending out the release notification. Release notes can be found on the RiverWare.org website.
The following twelve bugs were fixed:
*Bug 5963 detail: We determined that it is not always desirable for the run's initial timestep (one before the start-of-run) to be included in the automatically synchronized time range of RPL expression slots, applied in the course of expression slot evaluation. A persistent setting -- an "Include Initial Timestep in Run Period" checkbox -- was added to the Configure Timeseries dialog for RPL expression slots. This checkbox is off, by default, to replicate the prior behavior.
Additionally, analysis was done on the following bug:
Changes to RiverWare model file numeric precision:
In order to mitigate the risk of loss of information when floating point values are written to a model file, starting in RiverWare 7.2, most values will be written with full precision (17 decimal digits, in standard units). Through RiverWare 7.1 the default precision was 12 digits, so in order to balance the potential increase in file size due to the general increase in precision, users will be able to choose to use a lower precision for simulation results (defined series slot values with the Output or Rule flag). As part of this work, the Model Save Confirmation dialog was modified to present the new options.
Modification to begin and end run diagnostic messages:
RiverWare posts diagnostic messages at the beginning and end of each simulation which include the current "wall clock" time, as hours and minutes. The format of these times was modified to also include seconds.
RiverWare Visual Studio Upgrade (from VS 2010 to VS 2013):
In June 2017, CADSWES staff completed the Visual Studio Upgrade from VS2010 to VS2013 and pre-released RiverWare 7.1 build with Visual Studio 2013.
- The Visual Studio 2013 RiverWare development branch was merged to the master RW 7.1 branch.
- A snapshot was created and tested by CADSWES staff using a comprehensive test plan.
- Visual Studio 2013 was installed on all developer and release machines for use with RiverWare 7.1. This involved installing the new version of Visual Studio and associated tools, updating the machine environment and building the executables. In addition, for the release machines, the overnight build processes were updated and implemented.
- Install scripts were developed to configure development machines with the new environment.
- Developers installed the new environment and began regular development using Visual Studio 2013.
- RiverWare 7.1 was pre-released as a Visual Studio 2013 product.
RiverSMART Visual Studio Upgrade (from VS 2010 to VS 2013):
During the first few months of 2017 RiverWare was ported to Visual Studio 2013, including upgrading the 3rd party libraries RiverWare uses. RiverSMART is also built using Visual Studio, although it uses a small subset of the eighteen 3rd party library RiverWare uses. Usually this means that once RiverWare is ported it's a straightforward matter to port RiverSMART. In June RiverSMART was ported to Visual Studio 2013 and the upgraded 3rd party libraries, although the port wasn't as straightforward as expected, and the reason illustrate why the full scope of the necessary effort is hard to anticipate.
RiverSMART uses the zlib library to read compressed RiverWare model files (to "mine" the model files for metadata describing aspects of the model). RiverWare uses the zlib library for the same purpose. After its port, the RiverWare code (which was taken directly from RiverSMART) worked correctly. However, after its port the RiverSMART code was crashing in a call to the zlib gzopen() function. Same code, same library yet one application worked correctly and the other application crashed. (I say "same code," yet there were differences. For example, RiverWare calls gzopen() from the executable whereas RiverSMART calls it from a DLL. Is this a significant difference? It can be difficult to find the answer, and searching the Internet can consume a lot of time without yielding a definitive answer.) The time spent debugging the crash didn't reveal the problem (much less a solution), so attention turned to using a different zlib library. (There wasn't a good reason to think the zlib library was the problem, but sometimes something is tried for lack of something better to try.) Searching the internet identified the zlib implementation bundled with Qt 5.5.1 as a candidate, although there are those who say it shouldn't be used. (Their rationale is that Qt doesn't document that it uses zlib and therefore one should view zlib as a Qt implementation detail and not rely on it.) But having already spent more time than anticipated on the RiverSMART port, it was decided to use the zlib bundled with Qt. Should a future Qt release not provide zlib the decision will be revisited.
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.
Also, in June 2017:
- The tvaOptRPL test exhibited an apparent slow down due to the new CPLEX version. CADSWES investigated and found that it was likely due to the number of processors used, but there is nothing to do to address it in the short term.
- The regression tests were updated from version 7.0.8 to 7.1 in the prerelease and from 7.1 to 7.2 in the development area. This required a lot of attention to get the overnight builds and test operating correctly on the correct development area.
- An optimization regression test was observed to have increased its run time by 30%. It was determined that this was due to the upgrade of CPLEX from version 12.5.1 to 12.6, which was required by the upgrade to the Visual Studio 2013 compiler, and further analysis led to the conclusion that this slowdown could be mitigated by adjusting the number of threads made available to CPLEX, and that no further changes were required.
None reported for June 2017.
--- (end) ---