skip to main content
Optimization
New Warning
A new warning has been added to insure that the first approximation point of a spill upper bound approximation is less than the initial value of elevation or storage (depending on which is used in the linearization). Previously, cases that would generate this warning would lead to an infeasible linear program.
Conditional Constraints
Each constraint can now have conditions added to it by selecting a button in the constraint editor. The default is that no conditions are placed. The button options are no conditions, a condition expression, a time condition, or both. Both of these conditions appear as separate lines below the constraint.
The time condition specifies a range of valid model start times for the constraint in question to be valid. The range is specified as a pair of month/day entries. For example, a constraint used in the winter might have a time condition like "Nov 5 <= run start time <= Feb 15". These dates are editable.
The condition expression is built up from the expression editor. It should evaluate to true or false based on conditions known at the beginning of the run. The expressions use any of the following operators: <=, >=, =, <, or >. The left and/or right side of these expressions are linear expressions that would typically reference slots. Multiple conditions can be created by using the newly created “AND” and "OR" operators. As with other expressions, the expression editor will allow nonsensical expressions to be entered and the user has the responsibility of entering a reasonable expression. The new operators can in theory be used in formulating constraints and objectives as well, but there doesn’t seem to be any immediate practical benefit of doing so.
An example of a condition expression is:
“(((Boone.Pool Elevation[0] > 1600 "ft") OR (South Holston.Pool Elevation[-1] >
1700 "ft")) AND (AVG i FROM -4 TO -1, Watauga.Outflow[i] <= 100 "cfs"))”
Performance Improvement and Numerical Stability
Several technical changes were made to improve performance. The details are as follows.
• Variables with redundant bounds were changed to infinite bounds to reduce unnecessary pivoting.
• The upper bounds on variables were changed to use optimization units instead of internal units to prevent "infinite" bounds (by CPLEX’s definition) from being translated to finite bounds.
• The setting of the algorithm was moved so that either a primal or dual algorithm can be used to solve a linear program. The algorithm selected is based on the type of goal.
• A new capability was added to detect slow progress in the LP and trigger both a fresh "presolve" and a restart with a fresh basis.
• A new and more efficient CPLEX function, CPXtightenbds, was used to instead of CPXchgbds where ever possible.
• Several CPLEX parameters were adjusted to improve performance based on conversion to CPLEX 8.0 and changes in TVA’s problems.
• Frequently, when RiverWare is generating internal variable names for CPLEX non-slot variables, the name is similar to the previous variable; code was added to retain the last name generated and to reuse it when possible.
Numerical stability was dramatically improved by keeping floating point numbers stored as doubles throughout optimization. Previously, some numbers were converted to text during formulation of the optimization problem.
Instead of adding constraints with a single variable, the bounds on that variable are adjusted, thus reducing the size of the linear program.
Diagnostic capability was enhanced by adding dumpSAV, dumpBAS, and dumpPRE functions. These functions generate respectively a binary CPLEX problem and basis file, a text basis file, and a presolve file.
Revised: 08/04/2020