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

freeze protection issues in the VAVReheat example models #1995

Open
kuzha opened this issue Jun 6, 2020 · 2 comments
Open

freeze protection issues in the VAVReheat example models #1995

kuzha opened this issue Jun 6, 2020 · 2 comments

Comments

@kuzha
Copy link
Contributor

kuzha commented Jun 6, 2020

The two VAVReheat models ASHRAE2006 and Guideline36 in the package Buildings.Examples.VAVReheat have incorrect mixed air temperature TMix. When the AHU system is off and TMix is lower than the freeze protection setpoint at 4C, it invokes the freeze protection mode.

ASHRAE2006 model

Issue 1: incorrect outdoor air damper control for freeze protection

ASHRAE2006

The blue curves in the above figure show the results of the current implementation. TMix (shown in the upper plot) is as low as 4C when the AHU system is on. This is caused by the incorrect setpoint and measurement signals for the outdoor air damper control for freeze protection. More specifically, the setpoint and measurement signal for the block yOATFre in the economizer controller Buildings.Examples.VAVReheat.Controls.Economizer should be swapped. In the current implementation, yOATFre tries to cool down the mixed air temperature to the freeze protection temperature. After having swapped these two inputs, TMix increases to around 11C as shown by the red curve. This change also impacts the heating energy use as shown in the second plot.

Issue 2: simultaneous heating and cooling

The heating coil and cooling coil can be turned on simultaneously in the current implementation as the two coils use the same fan on signal from the block modeSelector. This is not obvious in winter in Chicago but has been detected using the weather of LA.

Guideline36

The mixed air temperature in the Guideline 36 model is incorrect when the system is off. TMix goes to negative in the evening (see the blue curve in the upper plot) and triggers freeze protection.
G36

This is caused by the exhaust air damper control setpoint which is 1 all the time. In the evening, the outdoor air damper is closed but some amount of outdoor air goes into the room through the exhaust damper. After changing the exhaust damper setpoint using yOutDamPos, TMix goes above freeze protection temperature (see the red curve in the upper plot). Since this happens when the system is off, there is minimal impact on the energy use.

@AntoineGautier
Copy link
Contributor

@kuzha I think the first issue you mention (incorrect connection of set-point and measurement signals for yOATFre in Buildings.Examples.VAVReheat.Controls.Economizer) is not a real one.

  • Currently the connection is indeed incorrect but yOATFre is configured with reverseActing=true. If you switch the connection so that TMix is connected to u_m then you must also set reverseActing=false as yOA should decrease with TMix. You end up with an equivalent behavior as before. (Nonetheless, for clarity, this new settings and connections should be implemented in my opinion.)
  • What makes TMix low in ASHRAE2006 is the minimum air flow rate which is set to 0.3*m_flow_nominal/1.2. In occupied mode, the ultimate yOA signal is never driven by yOATMix in winter, but always by conV_flow or yOATFre, see plot below. I believe this is the correct behavior and I do not understand how you managed to reach higher TMix values while still respecting the minimum air flow rate.
    PartialOpenLoop

@kuzha
Copy link
Contributor Author

kuzha commented Jun 26, 2020

@AntoineGautier
Thanks for checking out the first issue. I had a discussion with Jianjun and we still had some details to figure out to fix all issues I described (like the second issue may be a design choice, not really an issue). I will include you in the discussion in the future.

As to the first issue, I believe you are using the latest updates with changes from "reverseAction" to "reverseActing". When I raised the issue, the original setting is "reverseAction=false". Now it has been changed to "reverseActing=true", so it cancelled out the error.

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

2 participants