Required Model File Updates

Error Checking in PeakPowerCalc and PeakBasePowerCalc

Additional error checking was added to the PeakPowerCalc and PeakBasePowerCalc methods. The new errors enforce a positive peak flow volume (computed as Outflow minus Spill minus Base Flow, converted to a volume). A negative peak flow volume would result in the computation of negative Power and Energy values. This situation would occur whenever the Outflow is less than the sum of the Spill and Base Flow. According to Dr. Terry Fulp this is an error situation that should result in the run aborting with an error message notifying the user. This may occur if there was an error in the Maximum Controlled Release value or, more likely, if the Base Flow value is too great. One of our CRSS regression tests aborted with this error so it is highly likely that some CRSS models contain this error and will now abort with the new release. In this case the user must decide upon a new Base Flow value (set in the Base Flow Table slot), that will not exceed the Outflow. The error produced in this situation will read, “Negative peak flow volume calculated. Spill + base flow cannot be greater than outflow. Check Max Controlled Release slot and/or base flow values.” The left hand side of the diagnostics window will give the object and timestep on which this occurred (this occurred on Lake Havasu in our regression tests). The model must be fixed by reducing the value in the second column of the Base Flow Table. Contact Terry Fulp if questions arise about the appropriate value for Base Flow.

Upgrade to Tcl 8.2.3

The Tool Command Language (Tcl) that was previously used to write Rules was upgraded to version 8.2.3. The previous version of Tcl we were using was over six years old. It was necessary to upgrade to a recent version that is compatible with Windows NT. Our nightly regression test showed some model differences as a result of this upgrade. We believe these differences to be a result of a difference in the level of precision used in the two versions of Tcl. In one case, however, there was a syntax error in a Tcl function that was not detected by the old Tcl but was detected by version 8.2.3. In this case the model aborted and a diagnostic message pointed the user to the exact location of the Tcl error. If your model still uses Tcl functions, it is possible that you will encounter minor differences in model run results. These differences should be less than the convergence level (0.01%) and should not affect the policy outcome. It is also possible that your Tcl functions had syntax errors that were not detected by the previous version of Tcl and are now noticed by 8.2.3. If this is the case, your Tcl function will need to be fixed.

Minimum Efficiency Slot on the Water User

The Minimum Efficiency slot on the Water User object was changed from a Table Slot to a Series Slot. RiverWare automatically extends the time series range on this slot to match the Run Control Dialog. The single value held in the Table Slot is copied to every timestep in the series. So every model should be updated automatically to use the single table slot value for every timestep in the run. However, if the run dates of the model are changed, values for Minimum Efficiency must be input for the new timesteps. This can be done by hand or preferably through a DMI. If your DMI moves the timestep of your model ahead, then it should be modified to add data to the Minimum Efficiency slot. Another approach would be to extend the timeseries range on the Minimum Efficiency slot to include a very large number of timesteps. Then a value could be input on every timestep using the Fill Values command. This will work as long as the time series is expanded to encompass any possible run period.

(Variable) GainLoss Coefficient Restriction

The GainLoss Coefficient (or Variable GainLoss Coefficient) is no longer allowed to be -1.0 when a reach is solving upstream. A GainLoss Coefficient of -1.0 means that 100% of the Inflow to the reach is lost. When solving upstream given an Outflow value, it is impossible to determine a unique Inflow value if the GainLoss Coefficient is -1.0. Basically, an infinite number of Inflows could result in the given Outflow because 100% of it is lost before getting to the Outflow. RiverWare now detects this situation and flags an error when it occurs. Models that contain reaches that solve upstream and have a GainLoss Coefficient of -1.0 will abort when run in the new release. The GainLoss value must be changed to any number that is greater than negative 1.0.

Revised: 08/02/2021