Open j-bryan opened 1 year ago
Note heat loss is probably covered by the <RTE>
(round trip efficiency) node. Providing more complex functions for this node (than simple scalars) may introduce remarkable complexity to the optimization constraints, but should be approachable if needed.
Related to #88 which includes ramp rates generally
Yes, I suppose the implementation here would be essentially the same as for ramp rates in general.
I considered the
Yeah, extending RTE to be time-dependent would be state-of-the-art work. It moves the analysis from the regime of level/charging to further include integrated level of storage as a function of time. If solving 8760 continuous histories, this would be pretty straightforward to march through, and probably would yield manageable pyomo expressions. If solving clustered typical days, however, I think this time integration would become almost impossible to track effectively. I'm certainly interested in hearing how it could be approached!
Incidentally, I think this limitation is the reason for using RTE as a standard. While it's a homogenized metric, it seems to do a fairly reasonable job of expressing the storage efficiency without as much time-energy accounting.
Good points. Probably not worth the expense to model heat loss in that sort of detail. As long as the storage is cycled periodically, RTE is probably a good enough approximation.
Regarding ramp rates, do you think you all might take a look at that in the near future? If not, I'll look at it myself if/when it becomes immediately useful to us here.
As of this moment, I don't have any uses cases requiring ramp rates, so it's on the back burner. It might be good to check back in when it becomes apparent you'll need them, and we can see if our priority stack has shifted.
Issue Description
Is your feature request related to a problem? Please describe. There seems to be no simple way to modify the charge/discharge behavior of a component which. Without implementing a custom dispatcher, the charge and discharge rate of the storing component seems to only be limited by the other consumers and producers interacting with the stored resource (e.g. turbine capacity limiting storage discharge rate). I would also like to be able to set a loss rate for storage components.
Describe the solution you'd like I would like to be able to set the min/max charge/discharge rates from the HERON input XML. A subnode for where these bounds could be set would make sense to me, with minimum and maximum rates using the existing and tags. Heat loss rate could similarly be specified with a subnode. It would be helpful to be able to use both fixed values and functions (or DataGenerators, generally) to specify these values.
Describe alternatives you've considered Provide a sample custom dispatcher which implements these features.
For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.
For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.