Resource directionality constraint between components in HERON

[shigrekar1]

---

Currently in HERON, when a resource is produced, any of the components that can consume the resource will consume it during dispatch optimization. It would be nice to have control over which components could consume the available resource and how much of it.

Is your feature request related to a problem? Please describe.
I am modeling a case where a nuclear power plant is connected to a thermal energy storage (TES) system. The TES system is divided into three components - charge, storage, discharge (see attached layout). Of these three components, the charge consumes a resource (for eg. thermal heat) and produces a resource TES heat. This TES heat is supposed to be stored within the storage component, and during discharge, it is supposed to flow to the discharge component.

As it currently stands, the resource "TES heat" can be consumed either by the storage or the discharge component, which should not be the case. The TES heat should always flow through the storage component. As there isn't a possibility of converting the TES heat within the storage component to a different resource (storage only stores), this is an issue. There have been cases where the charge and discharge components communicate with each other while bypassing the storage component completely.

Describe the solution you'd like
If there was a way to dictate what components are allowed to interact with each other, that would solve this issue.

Describe alternatives you've considered
I have tried using a converter, but the issue still persists because the charge can then communicate to the discharge through the converter.

---

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?