This example is similar to Buildings.Fluid.HydronicConfigurations.ActiveNetworks.Examples.Decoupling except that an alternative control logic is implemented, based on the measurement of the return temperature in the consumer circuit and in the primary branch.
This control logic intends to keep constant the difference between those two
measurements.
Considering that we have:
T1, ret - T2, ret =
(ṁ1 - ṁ2) / ṁ1 *
(T1, sup - T2, ret),
the control objective can be expressed based on the
set point ΔTset and the consumer circuit
temperature differential ΔT2
(ΔT2 = T2, sup - T2, ret =
T1, sup - T2, ret)
as:
ΔTset =
(ṁ1 - ṁ2) / ṁ1 *
ΔT2.
For consumer circuits that have a temperature differential
relatively constant (see for instance
Buildings.Fluid.HydronicConfigurations.ActiveNetworks.Examples.ThrottleOpenLoop),
the control logic will thus maintain a
nearly constant fraction of primary flow recirculation.
However, at very low load if ΔT2 value
drops (due for instance to a secondary flow recirculation
ensuring a minimum flow for the secondary pump) the
control valve will be fully open, and the primary pump speed
potentially maxed out, trying to compensate for the vanishing
ΔT2.
In other words, taking the example of a heating circuit, at low
load the control logic cannot infer that the low
value of T1, ret - T2, ret is due
to a consumer circuit return temperature that is too high
(as it tends towards the supply temperature).
It will work under the assumption that T1, ret
is too low, and open the control valve to try and increase the
primary flow recirculation.
This flawed control is showcased in this example when the parameter
is_cor
is set to false
(the default), see
plots #1 and #2 between 14 and 16 h.
Now setting is_cor
to true
, a correction
is used to counteract this low load effect
by limiting the set point to the consumer circuit temperature differential
ΔT2.
Note that the implementation of that correction is specific to
a change-over operation and needs to be adapted for heating-only
or cooling-only applications.