[Feature] Allow components to both consume and produce a resource

[caleb-sitton-inl]

Motivation

It may be helpful for some use cases to have Components able to handle overlap between the sets of consumed resources and produced resources. For example, if a Converter is required that consumes electricity upon startup and generates electricity normally, we would have to use a workaround strategy to model it.

Design

The "flow direction" of resources could be tracked. This would probably be easiest in the model's flow variable.

Impact

The existing API would be the same, but the flexibility of Converters would be improved.

[GabrielSoto-INL]

As you mentioned in #38 (comment) looks like there is now no overlap between consumed and produced resources. I wanted to link that comment back here, it seems like the plan is not to implement the proposed feature here but instead introduce checking to ensure that no resource is both consumed and produced. I tried to provide some justification for this below, let me know if you agree and maybe create a new issue for resource checks?

Justification:

In the example you gave, if I'm understanding correctly, this would be a Component that converts a set of resources into electricity. But it also must consume a discrete amount of electricity to begin operations at t=0 (or whenever it starts converting resources into electricity)? I think either the startup constraints should be imposed on a linked Component (could be incorporated in a time varying minimum capacity that's nonzero at t=0 but zero elsewhere) or maybe it should be an additional parameter on all Components that adds startup conditions (cold vs. warm startup). The latter option probably requires binary decision variables to track when a component is powered on and off, which would be a significant feature update (and would be cool to incorporate in the future!). Regardless, it feels like that startup behavior is its own separate thing from resource conversion/transfer.

In chemistry terms, seems there may be two situations where you'd have a consumed resource (reagent) also show up as a produced resource (product).

1. Equilibrium reactions (e.g., something is dissolved in a solution of other resources and disassociates) which combine forward and reverse reactions at the same rate. So you can have a mixture of reagents and products in the same mixture but with a known ratio (equilibrium constant). Basically, the reaction stalls and isn't completed.
   • I feel like this gets into the world of kinetics and transient physics that is currently out of the scope for DOVE (maybe in the future)
   • If users have that equilibrium constant, they could probably just model this with a Converter and a Source with the proper ratios?
2. Phase change
   • Again, probably requires higher fidelity physics modeling since DOVE doesn't track resource properties (would be a major change for DOVE, maybe a new model? but definitely out of scope for now)
   • If approximations are fine, it'd probably be best for a user to define two separate Resources here, one at each phase (e.g. steam vs water) or state (e.g., steam extracted at [T,P,x]_1 and steam extracted at [T,P,x]_2)

So I think your decision in #38 is valid, maybe we'd want to add startup constraints as their own separate entity later? But ultimately, it seems there aren't many cases where you'd want a resource be both an input and output. And for those cases, there are not-to-complicated workarounds.