Bypass proof of concept

[tlmerbecks]

This PR provides a first proof of concept for the potentially new component bypassing functionality discussed in #600.

Definition

To summarise, a bypassed Component has no affect on the properties of the inlet and outlet streams - effectively the inlet and outlet streams are directly connected to one another.

Implementation

• adding a new Component property called status - this would eventually be added to every component. For the time being the default status is "active" and can be set to "bypassed" if a component is to be bypassed.
• adding a new Component method called get_bypass_constraints - this mirrors get_mandatory_constraints method and will eventually have to be implemented specifically for each component
• the Component preprocess method was adjusted to only add parameter functions if the component is active, otherwise only the bypass constraints are considered.

Example

In the following example bypassing the SimpleHeatExchanger ignores the parameters set (i.e. defining the duty and pressure ratio)

from tespy.networks import Network
from tespy.components import Sink
from tespy.components import Source
from tespy.components import SimpleHeatExchanger
from tespy.connections import Connection

nw = Network(p_unit='bar', T_unit='C', h_unit='kJ / kg')

source = Source("In")
sink = Sink("Out")
heater = SimpleHeatExchanger("Heater")

c1 = Connection(source, "out1", heater, "in1", "1")
c2 = Connection(heater, "out1", sink, "in1", "2")
nw.add_conns(c1, c2)

c1.set_attr(T=100, p=2, m=1, fluid={"water":1})
heater.set_attr(Q=2e6, pr=1)
heater.set_attr(status="bypass")

nw.solve("design")

nw.print_results()

Issues

• It is easy to create conflicts in variable specifications, as often the inlet/outlet conditions of a component are not defined at the Component level, but instead for the incomming/outgoing Connections...
• Adds unneccessary equations compared to removing the Component from the network, although with on-going refactoring in mind this may lose significance.