Due to many changes in the Rulebased Simulation Controller and Rule Processor over the past several releases, an overview is included at the end of these release notes. See the overview for a complete picture of the current Rulesbased Simulation logic.

The Rulebased Simulation controller now keeps track of Rule execution iterations. The iteration count is used to interrupt a run if a Rule executes more than 50 times in a single timestep. Previously, there was no way to interrupt infinite loops in the iteration between Rules and Simulation.

Checking of dispatch conditions is now delayed until all of a Rule’s slot assignments have been made. Previously, objects checked their dispatch conditions whenever a dispatching slot value was set. For Rules which only set a single slot, this created no ambiguity. For Rules which set multiple slots, however, this allowed objects to be placed on the dispatch queue even if the Rule had other slots yet to be set on this object. In some cases, the slots remaining to be set would have forced a different dispatch method to be selected. To alleviate any ambiguity, dispatch conditions are no longer checked until all of a Rule’s slot assignments have been made.

Errors generated during Rule execution calls to Simulation functions no longer abort the run. Errors are now returned to the Rule Processor for interpretation. Previously, any error generated in a Simulation engineering function which was called during the execution of a Rule automatically posted a message and aborted the run (the Simulation Controller still behaves this way). The Rule Processor, however, now catches simulation errors and terminates the executing rule instead. The rule does not continue, and no slot assignments are made. The rule may re-fire at a later time.

RiverWare Tcl procedures which invoke methods on the Engineering Objects are prevented from aborting the run. Since these functions solve hypothetical problems for the rules only and do not set slots, their failure should only impact the currently executing rule. All Tcl procedures, however, will continue to abort the run if fundamental errors are detected (incomplete arguments, invalid dates/times, etc.). The effects of errors in each of the currently defined Tcl procedures included in RiverWare are as follows:

The average Pool Elevation over the current timestep is now used to determine the maximum Release and Spill for C_getMaxOutflowGiven<Inflow/Storage/HW> Custom Tcl Routines. Previously, the Pool Elevation at the end of the current timestep (current Pool Elevation) was used. Now, the Pool Elevation at the beginning of the current timestep (previous Pool Elevation) is averaged with the most recent estimate of the Pool Elevation at the end of the current timestep. This average elevation is used in the Max Release/Max Turbine Q, Unregulated Spill Table, and Regulated Spill Table (if applicable) to determine the maximum Outflow.

The getMaxOutflowGivenInflow Custom Tcl Routine has been modified to not require a Pool Elevation value as a seed to the iterative solution. The new arguments for this function are as follows: