This section describes the predefined RiverWare ™ functions which are available for use in any RiverWare Policy Language (RPL) set.
Predefined functions perform a wide range of calculations common to water management policy and its expression in a rule context. Some predefined functions provide rules with access to the same algorithms used in RiverWare ™ simulation for mass balance calculations, flow/volume conversions, and table lookups. Other predefined functions are available for common mathematical operations, date/time manipulations, topographical evaluations, and some specialized river basin management calculations.
Predefined functions are used in RPL sets in the same way as user defined custom functions. They are selected from the palette, and inserted into a rule, internal function, or other expression. Each predefined function is an expression which evaluates to one of the 7 rules data types:
Predefined functions may or may not have arguments. The computational algorithms and arguments to predefined functions may not be modified.
This section presents an overview of a set of functions that allow the user to run a “hypothetical simulation” where:
Why would you want to do this? Lets consider the following example. Suppose that you would like to maintain a minimum flow of 100 cfs at some point in the River Y. Many miles upstream from this point you can control the outflow from Reservoir X. One question you might ask is: what is the release from X which will lead to the 100 cfs flow at the point of concern? A related but simpler question is: If I release 200 cfs from reservoir X, what will be the flow at the point of concern?
Even the answer to the second question can’t be easily predicted; you might have to take into consideration many hydrologic inflows and flow-dependent physical processes like lags, losses, and diversions through different sections of River Y. you might even require that you know the release over some extended period of time in order to be able to determine the flow in the Y at a single time. At any rate, this is exactly the sort of computation performed by the objects in a RiverWare simulation.
On the other hand, answering the first question requires not only knowing the physical consequences of outflow from X, but a search for the release which has the target consequence. The target consequence cannot just be set and allowed to solve upstream because there are routing algorithms can only solve in the downstream direction.
The following functions can be used to do hypothetical simulations:
Each hypothetical simulation function proceeds in the following manner. The first time the function is called, all of the objects and links in the specified subbasin are cloned. This copies each object including all of the slots and values. This cloning is necessary as all subsequent computations are performed on the cloned objects, thereby not affecting the real objects on the workspace. Once the objects are cloned, any values specified in the arguments as “fixed values” are set on the objects. Remember, the function also copied all its data at the time it was cloned, so the fixed values are values that are to be set on the object that are not already there.
Then, the hypothetical simulation performs the computations described for that function. For HypSim, the cloned objects will dispatch to simulate the effects of the fixed values. A list containing the values of the specified slots at the specified datetimes will be returned. The calling rule/function can then use these results in its computation.
HypLimitSim, HypLimitSimWithStatus, HypTargetSim, and HypTargetSimWithStatus perform an iterative solution. For each of these functions, you provide min and max values for a control slot and a target or limit of a downstream slot. The computations then boil down to univariate zero-finding, where each evaluation is a hypothetical simulation with different inputs. The solution is found using the bisection method as shown in the following figure; it simulates using the min control slot value (1), then the max control slot value (2), then bisects between the two(3). It continues bisecting until the tolerance or desired accuracy of the limit/target slot is met and a solution is found (N.) If the result of any try is outside of the range of previous tries, then a warning message is issued saying that the function is non-monotonic. There are either multiple solutions or the function is not well behaved. This typically leads to convergence issues.
Following are some notes to consider about hypothetical simulation and particularly the iterative hypothetical simulations: