Based on our conversation today, we talked about how it would be a major improvement to be able to model hurdle costs. I think this could be done linearly, relatively easily, possibly using the InterfaceLimit Modification. Right now there is an optional price column. I would propose the following:
- Make a
price_forward and a price_reverse column, removing the price column. Or have price column be a convenience thing for setting the same forward and reverse price. NOTE: the bi-directional hurdle cost only works for prices >= 0. If the directional price is less than zero, then pflow_if_forward and pflow_if_reverse would both get really big with no penalty. Make a check for this.
- Make a
pflow_if_forward and pflow_if_reverse variable, both constrained >= 0 and <= some pretty big number, possibly the sum of the line limits, possibly unbounded
- Constrain
pflow_if_forward - pflow_if_reverse = pflow
- Add an objective term for
pflow_if_forward * hour_weights * price_forward and pflow_if_reverse * hour_weights * price_reverse
Based on our conversation today, we talked about how it would be a major improvement to be able to model hurdle costs. I think this could be done linearly, relatively easily, possibly using the InterfaceLimit Modification. Right now there is an optional
pricecolumn. I would propose the following:price_forwardand aprice_reversecolumn, removing thepricecolumn. Or havepricecolumn be a convenience thing for setting the same forward and reverse price. NOTE: the bi-directional hurdle cost only works for prices >= 0. If the directional price is less than zero, thenpflow_if_forward and pflow_if_reversewould both get really big with no penalty. Make a check for this.pflow_if_forwardandpflow_if_reversevariable, both constrained >= 0 and <= some pretty big number, possibly the sum of the line limits, possibly unboundedpflow_if_forward - pflow_if_reverse = pflowpflow_if_forward * hour_weights * price_forwardandpflow_if_reverse * hour_weights * price_reverse