skip to main content
Combining Optimization With Simulation
Combining Optimization With Simulation
A complete RiverWare Optimization run makes use of a combination of the Simulation, Optimization and Rulebased Simulation. The motivation for this approach along with the details of each of the components are described in the following sections.
Standard Controller Sequence
A standard RiverWare Optimization run uses the Simulation - Optimization - Rulebased Simulation controller approach as follows: a Simulation run is made to clear any output values, check data, and propagate input values, then the Optimization is performed, and finally, a Post-optimization Rulebased Simulation is run to set the optimal values on the objects. Every run should be made as follows:
• Switch the run controller to Simulation, and click Start. Let the model run to completion.
• Switch the run controller to Optimization, load a Goal Set (if not already loaded), and click Start. Let the model run to completion.
• Switch the run controller to Rulebased Simulation, load a Ruleset (if not already loaded), and click Start. Let the model run to completion.
The use of the three controllers is described in more detail in the following sections.
The user starts with a model set up to run with the Simulation controller. The Simulation run serves five purposes described below.
Clear Output Values
This guarantees that leftover output data from a previous solution does not inadvertently get used in the current run.
Check for Required Inputs
Many Simulation methods check for required input data at the start of the Simulation run.
Pre-processing of Data
If the model contains initialization rules or expression slots that evaluate at the beginning of the run to pre-process data, these get evaluated during the simulation.
Propagate Input Values
Input values on linked slots get propagated across the links in the Simulation run so that they are properly registered as values for the corresponding variables.
Simulate where Possible
The Simulation run can also be used to simulate all aspects of the basin for which the user does not want to optimize. For example, the user might know that one reservoir may only release minimum flows during the run. Then the Outflow for that reservoir can be set as input to the minimum flow value for all timesteps, and the Simulation run will propagate the effect of this. Then in the optimization run, this reservoir is not considered.
Note:  A minimum flow requirement could alternatively be set by a high priority constraint in the Optimization Goal Set.
In most cases, after the Simulation run most slots of interest will still display NaN.
The solution of the linear goal program takes place during the Optimization run. During this run RiverWare takes the combination of the prioritized Optimization Goal Set and the model data (topology, physical characteristic data, time series data) and uses them to formulate a series of linear programs which it sends to CPLEX. CPLEX solves each linear program and returns the optimal values of the variables to RiverWare. See “Mathematics of Preemptive Linear Goal Programming” for details of the preemptive linear goal programming solution.
At the end of the Optimization run, RiverWare stores the final optimal value for every variable. At this point, no values have been set in slots on the workspace. That is to say that all slots which displayed NaN after the Simulation run will still display NaN after the Optimization run. Values will not be set in slots until the Post-optimization Rulebased Simulation, which is described in the following section.
Post-optimization Rulebased Simulation
After the run with the Optimization controller is completed, the Optimization solution is stored internally in RiverWare. Values from the solution are not yet returned to the workspace. All slots that displayed NaN at the end of the Simulation run will continue to display NaN at the end of the Optimization run. The solution is returned to the workspace by running a Post-optimization Rulebased Simulation. This is a special use of RiverWare’s Rulebased Simulation (RBS) controller. The Ruleset for a Post-optimization RBS does not typically reflect the operating policy of the basin as it would for a standard RBS. The operating policy is expressed in the Optimization Goal Set (though there is technically nothing to prevent formulating rules in the Post-optimization ruleset to override results from the Optimization solution with additional policies). Rather the rules in a Post-optimization ruleset set select values on the simulation objects, typically reservoir outflows, based on the values from the Optimization solution. With these values set, the simulation can solve fully for all remaining variables.
A second purpose of the Post-optimization RBS is to remove approximation error introduced by linear approximations in the Optimization solution. For example, Power must be linearized in the Optimization solution, introducing approximation error into the solution for Power. In the Post-optimization RBS, the reservoirs solve for Power using the full non-linear simulation method given the Outflow specified by the Optimization solution. This removes the approximation error introduced into Power from the linearization employed for Optimization.
After the Optimization run is complete, switch the Controller to Rulebased Simulation.
If no Ruleset is loaded when the controller is changed from Optimization to Rulebased Simulation, a message will appear asking if the user wants RiverWare to generate and load a ruleset. Either click Yes to use this automatically generated Ruleset for the Post-optimization RBS, or create your own custom set. See “Post-optimization Ruleset” for descriptions of these two options.
Post-optimization Ruleset
The final step of a complete Optimization run in RiverWare is a Post-optimization Rulebased Simulation (see “Post-optimization Rulebased Simulation”). The ruleset used for this special case of RBS can either be generated automatically by RiverWare, or a custom set can be developed by the user. These two options are described in the following sections.
Automatically Generated Ruleset
The automatically generated ruleset contains two policy groups. The first group (higher priority) is called “Set optimal Reservoir outflows.” The rules in this group set Reservoir.Outflow to the value from the Optimization solution by calling the OptValue() function. There is one rule for each reservoir, and they are ordered topologically. Specifically, the low to high priority order of rules corresponds to an upstream to downstream ordering of the associated reservoirs. Thus when using the default agenda order (...3,2,1), this causes the reservoirs to solve upstream to downstream.
Note:  If two objects are on different tributaries or in unconnected basins, then there is no constraint on the relative order of their associated rules. Reservoirs in a “No Optimization” subbasin are excluded from the automatically generated ruleset. Figure 3.1 is an example of an automatically generated Post-optimization Rule.
Figure 3.1   
The second policy group (lower priority) is called “Set optimal user defined variables values.” This policy group will only contain rules if the user has specified any user-defined variables (see “User-defined Variables”). The form of the rules is the same as those for reservoir outflows, but they set values on user defined variable custom slots. These user defined variable slots have no effect on the simulation when using the automatically generated Post-optimization Ruleset. Their values are set only for user reference.
If no ruleset is loaded when the user switches from the Optimization controller to the Rulebased Simulation controller after an Optimization run, then the user will be prompted regarding whether they would like RiverWare to generate an automatic Post-optimization Ruleset.
Custom Post-optimization Ruleset
In some cases, setting only reservoir outflows might not be sufficient for a Post-opt RBS. When Outflow is set on a Reservoir in RBS, the object will solve by putting as much of the Outflow through the turbines as is possible based on physical parameters. It will only use Spill if the specified Outflow is greater than the Turbine Capacity or if the Pool Elevation is above the crest of an Unregulated Spillway. This might be sufficient in a system where it is always desirable to prevent Spill, when possible. In some systems, however, a specified Spill amount might be required by an environmental policy. The Optimization Goal Set would likely contain one or more goals corresponding to this policy. In order to get the specified Spill into the Post-optimization RBS, a rule must set Turbine Release and Spill individually, rather than setting total Outflow (or alternatively set Outflow and Spill and let the model calculate Turbine Release). Other uses for a custom Ruleset are as follows:
• If other water uses, such as diversions, need to be specified in the RBS based on the Optimization solution.
• To refine the Optimization solution further in the Post-optimization RBS, possibly to make small adjustments to the flows once outputs have been calculated with the approximation errors removed.
• To add post-processing calculations to the Post-optimization rules.
A useful approach for creating a custom Post-optimization Ruleset is to begin with the automatically generated set. Then revise the rules as needed using the basic structure of the automatically generated set.
Once a custom Post-optimization Ruleset has been created, it can optionally be saved with the model file. Then the next time the model is opened, the Ruleset will automatically be opened and loaded. To save the Ruleset with the model file it must first be loaded. Then on the Run Control dialog select View, then Rulebased Simulation Run Parameters. In the resulting dialog, check the box for Save Loaded RPL Set with Model as shown in Figure 3.2. Close the dialog, and save the model with the Ruleset now included.
Figure 3.2   
Initialization Rules
Initialization Rules can be used for pre-processing of data for Optimization runs. See “Initialization Rules Set” in RiverWare Policy Language (RPL) for general information on initialization rules.
One use of Initialization Rules that is particular to Optimization is setting approximation points. Approximation points allow the user to control how non-linear processes are linearized. See “Linearization, Approximation and Replacement” for general information on linearization. See “Provide Approximation Points” for guidelines on setting approximation points.
In some cases, it might make sense to set the approximation points based on the specific run conditions. For example, for a reservoir that has a large seasonal variation in Pool Elevation, it might not be possible to set Tangent and Line approximation points in the Pool Elevation LP Param table or an Operating Head point in the Power LP Param table (when using the Independent Linearizations method in the Optimization Power category) that will result in sufficiently small approximation error across all conditions. In these cases, initialization rules can be used to set the approximation points such that the approximation error will be small for the expected operating range of the given run but would be large if operating in a different range in another season. Figure 3.3 is an example initialization rule that sets the Pool Elevation LP Param Tangent point equal to the initial Storage for the run.
Figure 3.3   
A second rule could set the two Line points to the Tangent point plus or minus some expected delta. In this manner, the approximations will be updated automatically when the model runs, rather than needing to adjust the values manually at the start of each run.
Note:  Initialization rules execute at the beginning of the Simulation controller run AND at the beginning of the Post-optimization Rulebased Simulation. They do not execute at the beginning of the Optimization controller run. Also note that initialization rules execute before pre-run expression slots. These execution times should be kept in mind when formulating the logic of initialization rules used for Optimization and which slot values they can reference.
Limitations of Optimization
The Optimization solution is based on a linear programming solution, and as such, has some inherent limitations as described below.
Optimization License Required
To use RiverWare's optimization solution, you must have the RiverWare With Optimizer version of the RiverWare license. (See for licensing information.) The license allows to you access RiverWare's optimization module, which embeds the third-party solver IBM ILOG CPLEX. Additional information about CPLEX can be found in the About RiverWare dialog (select About RiverWare... from the Help menu in the main RiverWare workspace).
Linear Relationships
All relationships must be linear or piecewise linear. This means that all means that all relationships that are non-linear must be converted to linear or piecewise linear approximations. RiverWare carries out this linear approximation automatically based on approximation points specified by the user. See “Linearization, Approximation and Replacement” for details.
Some common non-linear physical processes that must be linearized include the following:
• Power: A function of Operating Head and Turbine Release
• Turbine Capacity: A function of Operating Head
• Tailwater: A function of Outflow and (optionally) Tailwater Base Value (often downstream Pool Elevation)
• Operating Head: A function of Pool Elevation and Tailwater
• Unregulated Spill: A function of Pool Elevation
Linear Constraint Expressions
A corollary to the requirement that all relationship must be linear is that constraint statements can only contain linear expressions. This means that a constraint cannot contain a non-linear combination of variables. Also, to prevent the potential formulation of nonlinear expressions of variables in a constraint, RiverWare does not allow the use of IF/THEN expressions within a constraint statement (even if the IF/THEN expression does not contain a reference to a variable), nor the use of any RPL predefined functions within a constraint statement. Shown below are examples of constraint formulations that would not be valid.
Figure 3.4   
The constraint shown in Figure 3.4 contains a nonlinear combination of two variables, Turbine Release and Operating Head, and would cause the Optimization run to abort.
Figure 3.5   
The constraint shown in Figure 3.5 contains and IF/THEN expression within the constraint statement and would cause the run to abort. This type of logic can be achieved by putting the constraint statement within a WITH statement that carries out the IF/THEN logic. Figure 3.6 is an example of a valid goal.
Figure 3.6   
Figure 3.7 is an example of a valid use of IF/THEN logic in an Optimization goal outside of a constraint statement.
Note:  In this type of use, the expression in the WITH statement cannot contain a reference to an Optimization variable. Otherwise the expression would return an invalid value, which would cause the goal to terminate without writing any constraints.
Figure 3.7   
Figure 3.7 contains a RPL predefined function, Min, within the constraint statement and would cause the run to abort. User-defined functions can be used within constraint statements as long as the functions do not contain nonlinear functions of variables.
Approximation Error
A side effect of the requirement for linear relationships is approximation error. All variables that are linearized will have approximation error in the Optimization solution. Typically the largest and most significant approximation error shows up in the linearization of Power. In the Post-optimization Rulebased Simulation, the rules typically set flow values based on the values for those flow variables from the Optimization solution. Then the objects dispatch and calculate Power and other quantities based on the nonlinear Simulation methods. Therefore the calculation of Power in the Post-optimization RBS, once the approximation error from linearization is removed, will differ from the Power value in the Optimization solution. The Power approximation error tends to be most noticeable when the Optimization policy contains constraints that generation must equal some value (load). In these cases, the Optimization solution will often say that the constraint is 100% satisfied, but the Power calculated in the Post-optimization RBS will not match the constraint value exactly.
Solution Time
The computational requirements of the preemptive linear goal programming solution limit the size of the Optimization problem that can be solved in a reasonable amount of time. For large models (many objects and/or many goals) keeping the run length reasonable typically means limiting the number of timesteps. The definition of reasonable solution time is dependent on the use(s) of the model, and the user will need to determine what is an acceptable solution time. When determining the upper limit on the number of timesteps, one important point to consider is that the Optimization solution time for a given model does not increase linearly with the number of timesteps, as it generally does for RBS. The relationship between solution time and number of timesteps is typically somewhere between quadratic and cubic. The total solution time is a combination of a number factors, including but not necessarily limited to the following:
• Number of objects (roughly correlates to the number of variables)
• Number of timesteps
• Number of constraints
• Number of goals
• Difficulty of the solution (Objectives that force a lot constraints to be frozen or that have soft constraint violations can take longer to solve.)
• Hardware: Number of available processors, processor speed, memory
Perfect Foresight
The ability of the Optimization solution to look ahead in both time and space (global solution) is one of the benefits of Optimization. Optimization can be used to make sure you do not compromise you ability to satisfy constraints in the future when optimizing for today. However, if not managed appropriately, perfect foresight can be a potential weakness. Because the solution does not inherently put a higher value on one time period over another, in some cases it can exploit the solution to maximize an objective farther into the future, which has a result of degrading the objective in the near term. A common example would be if the value of Energy is somewhat higher later in the run. The solution might save as much water as possible until this higher value period and then generate at max capacity over the high value period. This might be considered a good solution, but in some cases there is more uncertainty about input data farther out in the forecast horizon, and it is not desirable for the solution to over-optimize these future periods at the expense of near term operations. This potential consequence of Optimization’s perfect foresight is important to keep in mind when considering the appropriate run horizon for an Optimization model.
Limited Objects and Method Selections
Not all object types are supported by Optimization. Additionally, only a subset of Simulation user methods can be used in conjunction with Optimization. See “Objects and Methods” for a complete listing of the available objects and methods. When creating a model that will be used for Optimization, it is important to make Simulation method selections that are compatible with Optimization.
The Optimization solution is generally more difficult to debug than Rulebased Simulation. Because it is a global solution, there is typically not a single cause for a bad output or odd result. It can be the combination of multiple constraints and input data at multiple locations and multiple timesteps. Often the solution can be exploited to improve some objective function if it is not properly constrained, resulting in unrealistic or undesirable operations. In these cases it can be difficult to determine what exactly is contributing to the undesirable result. See “Debugging and Solution Analysis” for descriptions of tools that can assist in debugging the Optimization solution.
Revised: 06/03/2019