Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of T_return in AixLib.Fluid.DistrictHeatingCooling.Demands.OpenLoop.VarTSupplyDpBypass is not robust #1475

Open
j-zipplies opened this issue Oct 25, 2023 · 0 comments

Comments

@j-zipplies
Copy link

Describe the bug
The model AixLib.Fluid.DistrictHeatingCooling.Demands.OpenLoop.VarTSupplyDpBypass seems to have an implementation of return temperature that is not robust: Whenever the bypass is active (= when the calculated mass flow is below the minimum mass flow), the return temperature should equal the supply temperature. However, this switching of temperature does not reliably occur when the bypass is active, it also may occurs at an undetermined moment or not at all, depending on solver settings.

To Reproduce
model Demo_Bug_VarTSupplyDpBypass
extends AixLib.Fluid.DistrictHeatingCooling.Demands.Examples.OpenLoopVarTSupplyDpBypass(sine.amplitude = 23000, demand.TReturn = 333.15, demand.m_flo_bypass = 0.1, sine.f = 1/1800);
annotation(experiment(StartTime = 0, StopTime = 3600, Tolerance = 1e-06, Interval = 18));
end Demo_Bug_VarTSupplyDpBypass;

(tested withAixLib 1.3.2 and OpenModelica v1.21.0 (64-bit) / OMSimulator v2.1.1.post188-gaf996ad-mingw on a Windows 10 Computer)

Expected behavior
Whenever the calculated mass flow is below the minimum mass flow (m_flo_bypass), the return temperature should equal supply temperature.

Screenshots
Result for mass flows and the lessEqual.y signal:
Demo_Bug_VarTSupplyDpBypass_mass-flows_lessEqual

Result for supply and return temperature:
Demo_Bug_VarTSupplyDpBypass_Temperatures

Although the load signal is a sine that is repeated twice, in the first "valley" the bypass temperatur is set as expected, whereas at the second "valley" it remains at the lowest value, until the end of the valley, where a short switching occurs.
Changing the settings for solver tolerance and/or interval may lead to different results (the smaller tolerance and interval, the more likely both bypass operations are modeled correctly).

Additional context
Sugested improvement:
The "switch1" component does the temperature switching. Its boolean connector u2 is connected from "lessEqualThreshold", which is connected from "smoothMax". Thus, the input signal to "lessEqualThreshold" may only be below m_flow_bypass during the transition when "smoothMax" changes between u1 and u2 within x_small. Depending on the solver settings, a simulation may "overrun" this short transition and fail to trigger the "lessEqual" condition.
I suggest to rather connect hea2MasFlo.y to lessEqualThreshold.u. Then, whenever the mass flow according to heat load is below m_flo_bypass, the minimum mass flow is maintained and the return temperature switches immediately. This should be a robust implementation of the bypass return temperature.

This issue most likely also applies to AixLib.Fluid.DistrictHeatingCooling.Demands.OpenLoop.VarTSupplyDpFixedTempDifferenceBypass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant