The iteration technique for the solveMB_givenInflowRelease dispatch method on reservoir objects has changed. As a result of this, the method may converge to slightly different values (within the convergence limit). This can be fixed by decreasing the value in the Convergence slot. Also, it may be necessary to increase the number in the Max Iterations slot. If you are seeing a warning message that says “Internal loop reached the maximum iterations of ...” then you need to do this.

This new iteration technique is a bisection method that is bounded by the maximum and minimum pool elevation values in the Elevation Volume Table. Therefore, this requires the same range of values for pool elevation in the spill, max release, and elevation volume tables. For example, if the elevation volume table ranges from 0-2400 ft, then the spill table needs to go from 0-2400 ft. If these tables are inconsistent in an existing model, the model will not run in this release until the tables are updated.

The Inline Power object was enhanced to include the following general slots: Turbine Release, Max Turbine Release, Plant Capacity Fraction, Bypass, Min Bypass, and Hydro Capacity. The addition of the Max Turbine Release slot will cause existing models (that use the Inline Power object) to abort. A Max Turbine Release value must be input in order to fix the model. The user should be aware that the units for all of the new slots will be standard RiverWare units and users must configure them accordingly.

Two of the GainLoss Calculation methods on the Reach object, Seasonal GainLoss Flow Table and Interpolated Flow GainLoss, are no longer valid methods when Time Lag Routing is the selected routing method on the reach. The reason for this change is that it is impossible to get the same answers solving upstream and downstream when using Time Lag Routing with one of these loss methods. Therefore, we disabled these two methods when Time Lag Routing is selected. If an existing model has a reach with both Time Lag Routing and one of the two loss methods mentioned above, RiverWare will give the following warning message when loading the model in the 4.1 release: “The <loss method name> method is no longer available when using timeLagRouting. You will need another reach to do the Gain Loss calculations. ...” If this happens, the GainLoss method on the reach in question will be changed to No GainLoss. You will need to create a separate reach object to do the Gain Loss calculations.

 

Several new predefined functions have been added to the rules palette. Since these are very general functions, and have very general names, there is a possibility for naming conflicts with existing rulesets. For example, one of the new functions is call “Sum”. If an existing ruleset contains a user defined function or variable called “Sum”, the ruleset will not load in the new release. The user will get an error message when loading the ruleset. The message explains exactly where the conflict is located. In order to load the ruleset in the new release, the user will need to modify the ruleset to alleviate the conflict. This is done by changing the name of the user defined function or variable.

There are two ways to compute the GainLoss slot on Pass Through Accounts. One way is to specify a GainLoss coefficient on the account. This will compute GainLoss as a percentage of the inflow to the account. The other way is to set GainLoss directly using an object level accounting method. Prior to this release, the user could theoretically give a GainLoss coefficient and set the GainLoss slot with a method. Obviously this is an overdetermination. However, instead of giving an error, RiverWare just ignored the GainLoss coefficient. In the 4.1 release, this will result in an error. If this is happening, the user needs to either turn off the method, or remove the GainLoss coefficient.