[TASK] Specify max charge/discharge rate and loss rate of storage component from HERON XML file

[j-bryan]

---

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 <loss_rate> 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.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

---

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
• 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

[PaulTalbot-INL]

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.

[PaulTalbot-INL]

Related to #88 which includes ramp rates generally

[j-bryan]

Yes, I suppose the implementation here would be essentially the same as for ramp rates in general.

I considered the node, but this doesn't penalize holding storage over time like a loss term would. This loss term isn't crucial for us, just something I had expected to have as an option but didn't, yet could be useful.

[PaulTalbot-INL]

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.

[j-bryan]

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.

[PaulTalbot-INL]

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.