Setting Up and Running an Optimization Model
Optimization
Setting Up and Running an Optimization Model
This section provides a broad outline of the process of creating a RiverWare model designed for use with the Optimization controller.
Select Timestep and Run Range
The timestep and run range for Optimization are set in the Run Control dialog just as for Simulation models. The same timesteps are available for Optimization as for Simulation; however due to the nature of Optimization, some additional issues should be considered when setting the timestep and run range for Optimization.
During an optimization run a linear program (LP) is created which represents the physical and policy constraints for the system. The time required to solve the LP is related to the size of the model, including the number of objects, the number of timesteps in the run, and the number of constraints. Thus to permit a simulation that runs in an acceptable time, one might need to consider increasing the timestep length and/or shortening the run duration. It is important to realize that the run time for Optimization does not increase linearly with the number of timesteps. The run time tends to increase with something between the square and the cube of the number of timesteps.
Another reason for limiting the duration of an optimization run is that long optimization runs can exhibit perfect foresight. That is, since each LP solution optimizes over the full run duration, it can incorporate behavior that would not be plausible for operators who at any point in time do not have perfect knowledge of future events. Thus as a rule of thumb, optimization models should have a run duration no longer than the time frame for which accurate forecasts are likely to exist for the river basin operations.
Caution:  Although all timestep lengths are available for Optimization, it is not recommended that a 1 Month timestep be used with Optimization. Optimization does not have a concept of current timestep. Thus a 30 day month is used for all calculations and constraints that incorporate the timestep length, for example, conversions between volume and flow and between power and energy. As such, the mass balance in the Optimization solution will not match the mass balance of the Post-Optimization Rulebased Simulation for a 1 Month timestep.
Set Up and Test a Simulation Model
Before running a model with the Optimization controller, the model should be set up and run in Simulation mode. This allows for checking that all required input data have been provided and also allows for calibration of the physical model. A model should be validated using Simulation (or Rulebased Simulation) before trying to use it for Optimization. Also, recall that a complete Optimization run actually consists of a sequence of three runs using the Simulation, Optimization and Rulebased Simulation controllers (see “Standard Controller Sequence”), so a working Simulation model is a requirement for running with Optimization.
One common approach is to run the model in Simulation using historic Inflow and Outflow data as inputs and allowing the model to calculate Storage, Pool Elevation, Power, etc, which would be checked against the historic values. Then the Outflow inputs would be removed when running in Optimization to let the Optimization solution set the Outflows.
Note:  When setting up a Simulation or Rulebased Simulation model that will eventually be used for Optimization, it is important to keep in mind that not all objects and Simulation methods are supported by Optimization. Thus the object and method selections in the Simulation model must be made such that they are compatible with Optimization. See “Objects and Methods” for descriptions of the objects and methods that are supported by Optimization.
Select Optimization Methods
Many method categories apply only to the optimization controller, and some method selections which are appropriate for Simulation or Rulebased Simulation might not be so for an optimization model. Therefore, one must visit several categories and make appropriate selections. See “Objects and Methods” for descriptions of the optimization-specific categories and methods.
Note:  Not all Simulation objects are supported in Optimization. See “Objects and Methods” for a list of the only objects that can be included.
The Optimization method categories are only visible on simulation objects when the Optimization controller is the active controller selected on the Run Control dialog.
Once the Optimization has been selected, Optimization method selections can be made in the same manner as Simulation methods on the Methods tab of each simulation object (or through the multi-object method selector).
In some cases, a single method is selected for both Simulation and Optimization. For example, if the Time Lag routing method is selected for a reach object, then the appropriate routing constraints will be added in Optimization based on the Time Lag provided for the Simulation method. There is no need in this case to select an additional method for Optimization.
In other cases, an Optimization method must be selected that corresponds to a Simulation method. For example if the Base Value Plus Lookup Table method is selected for the Tailwater category, then Opt Base Value Plus Lookup Table should be selected in the Optimization Tailwater category. The optimization method will add slots that will be used to linearize the Tailwater variables. The linearization will use a combination of slots specific to the Optimization method as well as the Tailwater Tables from the Simulation method. See “Objects and Methods” for additional information on the selection of appropriate methods for Optimization.
A single thermal object models basin-wide quantities such as the total value of storage across all reservoirs in the model. The thermal object also includes economic modeling of basin-wide power generation. A thermal object is not required for an Optimization model, but it can facilitate the modeling of common hydropower objectives. See “Thermal” for additional information on the thermal object.
The thermal object acts as a summarizing object for many variables that may be included in an optimization policy. It summarizes information by linking to each of the reservoir or other objects of interest. For example, to compute the total energy produced in the model, the Thermal.Hydro Generation slot should be linked to each PowerReservoir.Energy slot. Other possible links include:
• Thermal.Hydro Generation <------> PowerReservoir.Energy
• Thermal.Total Cumulative Storage Value <------> Reservoir.Cumulative Storage Value
• Thermal.Spill Cost <------> Reservoir.Spill Cost
• Thermal.Future Value of Used Energy <------> Reservoir.Future Value of Used Energy
• Theraml.Energy in Storage <------>Reservoir.Energy in Storage
• Thermal.Hydro Capacity <------> Reservoir.Hydro Capacity
If a thermal object is used in the model, these links will need to be created.
Enter Lower and Upper Bounds
Bounds on Variables
Upper and lower bounds must be entered for all series slots that are decision variables. The values should be reasonable. They represent the absolute minimum and maximum for the slot. Often these minimum and maximum values are based on the actual physical minimum and maximum. For example, the Pool Elevation Lower Bound should be the bottom of the reservoir and the Upper Bound should be the top of the reservoir as found in the Elevation Volume table. Turbine Release should be limited to zero as the lower bound and turbine capacity for the upper bound. In other cases, the absolute physical minimum or maximum may not be well-defined, such as maximum Inflow (or if economic variables are included in the model).
These variable bounds remain constant and are automatically converted by RiverWare into hard constraints on the variable for every time step in the optimization solution. In these cases variables without an obviously defined minimum or maximum, the slot bounds should not unnecessarily constrain the problem. These types of variables will typically be limited, either directly or indirectly, through the constraints in the Optimization Goal Set. It is also important, however, that the slot bounds not be set arbitrarily large or small (i.e. orders of magnitude different than the realistic limits) as this can result in numerical instability due to scaling issues in the optimization problem. There is a tendency to enter data just to get the model to run. This can lead to later errors and difficulty debugging when these values inadvertently limit the solution of the problem.
It is important that slot bounds not be confused with policy constraints, nor be used to apply policy constraints. For example, a hydro plant might have a minimum generation requirement that it must meet, but the Power slot Lower Bound should still be zero. The minimum generation requirement would be set through a constraint in the optimization goal set. The slot bounds become hard constraints in the optimization problem and essentially remain constant in the model, whereas policy constraint values (usually stored in custom slots) are typically incorporated as soft constraints and may change for different runs.
The slot bounds do not affect the Simulation solution. They are only applied in the Optimization solution. The Simulation solution is limited only by the physical characteristics described in table slots such as the Elevation Volume Table and Plant Power Table. Often it is helpful to set the slot bound slightly inside min/max values for the corresponding data table. This prevents problems of exceeding values in the data table associated with approximation error when going from Optimization to the Post-optimization RBS. For example, if the highest Pool Elevation in the Elevation Volume Table slot is 1000 ft, the Pool Elevation slot Upper Bound should be set to something like 999.95 ft. See “Variable Bounds” for additional information on how variable bounds are used in the solution.
Setting Bounds
Note:  On Agg Series Slots, a value must be entered for each column.
There are two ways to set the Bounds.
1. From each slot, open the Configuration dialog (View, then Configure) and enter the Upper and Lower Bound.
2. Values on multiple slots can be set at once using the global slot configuration dialog accessed from the Workspace, then Slots, then Configure Slots menu (see “Global Slot Configuration” in User Interface). Select the Optimization option, and verify the Bounds on Series Slots check box is selected.
Optimization Limits for Data Verification
Certain Table Slots are verified to ensure they are increasing or satisfy requirements for concavity. Some tables meet the more stringent requirements of Optimization when a reservoir is within a normal operating region but violate these conditions during extreme events such as a flood when optimization would not be used. Users can optionally limit data checking in Optimization to the normal region by specifying Lower and Upper Limits. This allows extreme values to be in the table so that the model can be used for extreme events, but the extreme values are not used for Optimization purposes and they are ignored in Optimization verification in order to prevent the verification from failing. The specified range is configured in the Optimization Limits for Data Verification in the Table Slot configuration (shown in the screenshot) or using the Global Slot Configuration dialog described above (check the box for Optimization Limits for Table Verification). Some tables are automatically derived from other tables by RiverWare. For example spill tables based on elevations are automatically converted to spill tables based on storage. When the original tables have upper/lower limits, RiverWare automatically converts the original limits to their equivalent values for the derived tables, e.g. from elevation limits to storage limits.
For three-dimensional tables, this logic may be applied both to the range of z values and to x or y within a block of constant z values.
Only select table slots have limited data checking enabled. This is the current list of those slots for Reservoirs if the slots exist based on controller and method selections:
• Bypass Table
• Elevation Volume Table
• Energy In Storage Table
• Marginal Storage Value Table
• Regulated Spill Table
• Unregulated Spill Table
• Volume Area Table
The following tables are automatically created for Reservoirs by RiverWare by converting elevation based spill tables to storage based tables.
• Bypass Capacity Table
• Regulated Spill Capacity Table
• Unregulated Spill Linearization Table
The limits on these tables are set automatically based on the original tables’ limits.
In addition to these slots, Power Reservoirs have the following slots verified if the slots exist based on controller and method selections:
• Maximum Turbine Q
• Plant Power Table
• Stage Flow Tailwater Table
• Tailwater Table
The following tables are automatically created for Power Reservoirs by RiverWare by converting elevation based spill tables to storage based tables.
• Auto Max Turbine Q
• Convolved Stage Flow Tailwater Table
The limits on these tables are set automatically based on the limits in the Plant Power Table and the Stage Flow Tailwater Table respectively.
If the limits values are omitted on a table slot, then there will be no lower limit or upper limit respectively on checking that the table conforms to optimization requirements. The full range is checked.
Provide Approximation Points
When one modeled quantity (slot) is related to one or two other modeled quantities by a non-linear function, then that function must be approximated as one or more linear functions. RiverWare supports three basic ways of approximating a two dimensional function:
• Tangent - the tangent to the function at a given point
• Secant - the line passing through two given points
• Piecewise - several lines connecting points on the function
See “Variable Substitution” for details about each approximation technique.
Select Optimization methods use their own linearization method that does not depend on the tangent, secant and piecewise approximations. The information in this section does not apply for those methods. In the Optimization Power category, the Power Coefficient method and the Power Surface Approximation method are two such methods. See “Power Coefficient” and “Power Surface Approximation” for details. For those methods, a separate set of approximation parameters are entered as described in the section on each method. In the Optimization Tailwater category, the Opt Coefficients Table method uses the same table of coefficients as the corresponding Simulation method to define Tailwater Elevation (i.e. the Simulation method is already a linearized expression of Tailwater). See “Opt Coefficients Table” for details.
Data Table Slots
Each slot being approximated is related to another slot by a data table. Each row of the table provides a point in the curve describing the relation between the two quantities. In the case of 3-dimensional functions, multiple curves are described in the table.
• 2-D example: Elevation Volume Table, relates Elevation to Storage for a Reservoir.
• 3-D example: Plant Power Table, describes Power as a function of the Operating Head and Turbine Release. The table is organized as several curves, corresponding to Power as a function of Turbine Release for various Operating Heads.
Optimization uses the same data tables that are used in Simulation, or generates the required table automatically based on tables used in Simulation. Thus, a model that runs in Simulation should contain all of required data in data tables to run in Optimization.
LP Param Table Slots
Linear programming parameter tables (LP Param Tables) are specific to Optimization and are required input for an Optimization model. These slots become visible when the Controller is switched to Optimization. The LP Param table slots contain the points to be used when each approximation technique is applied. Setting the values for the LP Param tables can be one of the more challenging aspects of setting up an Optimization model. Setting poor approximation points can result in model infeasibilities that are difficult to debug. Figure 6.1 is an example of a Pool Elevation LP Param table. Basic guidelines for setting LP Param table values follow.
Figure 6.1
• The Tangent approximation requires a single point. The single approximation point for the tangent approximation should typically be set in the middle of the range of values expected to occur during the current run. The Tangent approximation will overestimate the approximated value for a concave function and underestimate the approximated value for a convex function. See “Tangent Approximation” for details.
• The Line (Secant) approximation requires two points. They should typically be set near either end of the range of expected values. The Line approximation will overestimate a function at some points and underestimate the function at other points. See “Two-point Line Approximation” for details.
• The Piecewise approximation requires two or more points. See “Piecewise Approximation” for details. For piecewise approximation, often it is sufficient to choose the three points used for the Tangent and Secant approximations. In other cases, finer granularity might be required.
Note:  Points are entered into the LP Param tables in terms of the independent variable(s) not the dependent variable. For example, the values in the Pool Elevation LP Param table slot are in terms of Storage, not Pool Elevation.
For three-dimensional approximations, the approximation point for the second independent variable (first column in the table) should be somewhere near the middle of the expected operating range. An example of a three-dimensional LP Param table is shown below. For the Power approximation, Turbine Release is the first independent variable and has points set for the Tangent, Line and Piecewise approximations. Operating Head is the second independent variable. A single value is set for Operating Head in the Power LP Param table, and Power is calculated based on this single Operating Head in the Optimization run.
Turbine Capacity Approximation
The Turbine Capacity linearization will always use the Piecewise approximation. Poor Turbine Capacity approximation points can lead to runs that fail in the Post-optimization Rulebased Simulation due to flows that exceed the actual Turbine Capacity in RBS, once the approximation error is removed. When setting the Piecewise points in the Turbine Capacity LP Param table slot, four criteria should be met.
• First, the piecewise curve must be concave. The optimization solution will not behave correctly if the piecewise curve is not concave, and thus the optimization run will abort with an error if the approximation points define a piecewise curve that is not concave.
• Second, the approximation points should cover the full range of operating heads in the Plant Power Table. If the points do not cover the full range, the optimization solution will use a linear extrapolation beyond the highest and lowest approximation points. This can result in excessive approximation error for upper and lower operating heads.
• Third, the piecewise curve defined by the approximation points should never be greater than the curve defined by the Plant Power Table (Auto Max Turbine Q slot). This can result in the optimization solution allowing turbine releases that exceed the actual Turbine Capacity in the post-optimization simulation. In other words, the piecewise curve from the LP Param approximation should always be under the curve defined by the Auto Max Turbine Q table.
• Fourth, the approximation points should be set such that the difference between the piecewise curve and the Auto Max Turbine Q curve is minimized. This reduces the approximation error in the optimization solution. If the difference between the two curves is excessively large, the optimization solution may overly restrict the turbine release to a capacity significantly lower than the actual turbine capacity for the given operating head.
One strategy than can help with picking points for the Turbine Capacity approximation is to plot the Auto Max Turbine Q slot and visually identify reasonable approximation points. The Auto Max Turbine Q slot is automatically populated by RiverWare at the start of the run (even if the run fails). It might be necessary to run the model fist in order to populate the table.
Because the Turbine Capacity linearization always uses the piecewise approximation, it is not necessary to set points for the tangent and line approximations. If values are set for these other two approximations, it will not cause a problem. They will simply never be used. If in doubt, set points for all of the approximations and let RiverWare select the appropriate approximation points to use. If values are missing for an approximation that RiverWare tries to use, the run will abort with an error message notifying the user of the missing values.
Power Approximation
The power approximation tends to be the linear approximation that introduces the most approximation error into the optimization solution. If the Independent Linearizations method is selected in the Optimization Power category, the Power LP Param table is used to define the Power approximation. The table contains an additional initial column for Operating Head in addition to the Tangent, Line and Piecewise columns with Turbine Release values. In the Optimization solution, a single piecewise linear curve for Power as a function of Turbine Release is used. This corresponds to one block of constant head in the Plant Power Table. Operating head is held constant at the value specified in the Power LP Param table. The remaining columns in the Power LP Param table set the Turbine Release for the approximation points.
Typically the Operating Head value in the Power LP Param table should be set to the average Operating Head expected in the run.However, in some cases it might be less problematic to overestimate Power than to underestimate Power. In these cases, it might make sense to set the Operating Head value in the Power LP Param table near the lower end of the expected operating range. This would cause the Optimization solution to underestimate Power, and thus the Post-optimization Rulebased Simulation will calculate a large Power value than the Optimization.
Initialization Rules to Set Approximation Points
n 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 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. For example, an initialization rule could set the Pool Elevation LP Param Tangent point equal to the initial Storage for the run as shown in Figure 6.2.
Figure 6.2
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.
Create an Optimization Goal Set
The Optimization policy must be cast into a set of prioritized goals. Like a RBS Ruleset, an Optimization Goal Set is a prioritized list of goals (written in RPL). However, whereas the rules in a RBS Ruleset are all executed at each timestep and set values, Optimization Goals are each executed once during a run from highest priority to lowest priority and have the effect of modifying or solving the current linear programming problem.
RBS rules are normally ordered to execute in an upstream to downstream order, object-by-object. Generally there is no need to order Optimization goals in an upstream to downstream order. The priorities of the goals should correspond to their true priorities in operations. The highest priority goals should correspond to the most important operating constraints, those that should essentially never be violated.
A single goal can contain constraints for multiple objects, but it is generally recommended that a single goal correspond to a single operating policy. For example, the highest priority goal might contain the license maximum Pool Elevation constraints for all reservoirs at all timesteps. The second goal might contain the license minimum Pool Elevation constraints for all reservoirs at all timesteps. This is generally better practice than placing the minimum and maximum elevation constraints in the same goal or placing the minimum elevation constraint in the same goal (same priority) as a minimum flow constraint. When multiple policies are combined in a single goal, it is not always obvious how the policies will trade off with one another if it is not possible to satisfy all constraints at that priority.
Medium priority goals generally contain constraints that you expect to get satisfied most of the time but that may not be possible to satisfy under some operating conditions, for example under extreme high or low flows. Lower priority goals typically contain target operating constraints, targets that you would like to meet under ideal conditions but are expected to be frequently violated due to higher priority constraints and input data (e.g. inflows). For example, you might have a low priority goal to keep flows equal across all reservoirs on each timestep, but most of the time you cannot keep flows exactly equal due to other requirements on the system. Typically the lowest priority contains an objective function to optimize with the remaining degrees of freedom given all higher priority constraints. For example, the objective might maximize the total value of hydropower generation during the run within the operational limits specified by higher priority constraints.
Figure 6.3 is a simple example of an Optimization Goal Set.
Figure 6.3
See “RPL Optimization Goal Set” for additional information about the Optimization Goal Set. See “Statements in Goal Sets” for details about the individual statements that make up Optimization Goals.
Create a Post-optimization Ruleset
RiverWare will automatically generate a Post-optimization Ruleset if there is no ruleset loaded when switching from the Optimization controller to the Rulebased Simulation controller upon completing a run with the Optimization controller. The automatically generated ruleset contains rules to set each reservoir Outflow slot to the Outflow value from the Optimization solution.
Reservoir.Outflow[] = OptValue(Reservoir.Outflow, @”t”)
See “Automatically Generated Ruleset” for details about the automatically generated ruleset.
In many cases it is necessary to customize the Post-optimization Ruleset to do more than simply set reservoir Outflows to the Optimization values. Some common uses for a custom ruleset might be:
• A need to set Turbine Release and Spill independently based on their Optimization values rather than just total Outflow.
• 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.
While the Post-optimization Ruleset is a special case of a ruleset used specifically in the context of an Optimization run, from a technically perspective, it is the same as any RBS Ruleset. As such it can contain any components that might be in a standard RBS Ruleset. For example, there is nothing to technically prevent the Post-optimization Ruleset from completely overwriting the Optimization solution. It is the use of the OptValue function when setting the slot in the ruleset that ties to the Post-optimization Rulebased Simulation to the Optimization solution. The Post-optimization Ruleset can make use of as much or as little of the Optimization solution as desired as long as it adheres to all standard requirements for a RBS Ruleset.
That being said, the standard approach is to have rules set flows based on the Optimization solution and let RiverWare calculate all remaining values in Simulation. When using this standard approach, it is strongly recommend to write the rules such that they maintain the overall mass balance from the Optimization solution. This is because the feasibility of the Optimization solution is dependent on the mass balance used in the Optimization solution. In addition the satisfaction of policies such as Pool Elevation constraints in the Optimization solution is dependent on the mass balance.
As an example, Post-optimization Rules that adjust the solution by making shifts between Spill and Turbine Release but use the same total Outflow as the Optimization solution would maintain the mass balance from the Optimization solution. Whereas rules that modified the total Outflow from the Optimization solution would alter the mass balance. In the later case, it would be possible to have a run where the Storage exceeded the limits in the Elevation Volume Table in the Post-optimization Rulebased Simulation, causing the run to abort, even though it was within the required limits in the Optimization solution (or less severely violate elevation constraint limits in the Post-optimization Rulebased Simulation when they were satisfied in the Optimization solution). Of course it is possible to include logic in the rules to check for these issues, but the more this type of logic is included in the ruleset, the more the solution will tend to deviate from the Optimization solution and become more of a Rulebased Simulation solution. Depending on the intended use of the model, this may or may not be acceptable.
Once a custom Post-optimization Ruleset has been created, it can be saved as a separate file just like a standard RBS Ruleset by selecting File, then Save RBS Ruleset As from the Ruleset Editor dialog and/or it can be saved in the model file. Once a Ruleset has been 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. Close the dialog, and save the model with the Ruleset now included.
Run the Model
Every run should be made as follows:
1. Switch the run controller to Simulation, and select Start. See “Simulation” for details.
After the Simulation run, most slots of interest will still contain NaN.
2. Switch the run controller to Optimization, and click Start. See “Optimization” for details.
The Optimization run will take considerably longer than the Simulation run. During the Optimization run, the Run Status dialog will report which priority is currently executing form the Optimization Goal Set rather than a timestep as for Simulation. After the Optimization run, all slots that contained NaN after the Simulation run will continue to display NaN. The Optimization solution is only stored internally and has not been returned to the workspace.
3. Switch the run controller to Rulebased Simulation. If no Ruleset is loaded either accept the option to (automatically) generate and load a Post-optimization Ruleset, or alternatively load a custom ruleset, and then click Start. See “Post-optimization Rulebased Simulation” for details.
After running the Post-optimization Rulebased Simulation, all slots of interest should be populated with data.
Note:  It is important to always run Simulation before running Optimization. Running Optimization without first running Simulation will not produce the desired results as data might be leftover from a previous run, or necessary preprocessing of data by initialization rules or expression slots will not be carried out.
An alternative to automate the three run sequence is to use a RiverWare script with actions to Set Controller and Execute Run for each of the three individual runs. See “Managing Scripts” in Automation Tools for details on how to configure and use a script.

Revised: 06/03/2019