Question-and-Answer Resource for the Building Energy Modeling Community
Get s tarted with the Help page
Ask Your Question
2

Cycling zoneHVAC components: tolerance of availability manager

asked 2016-03-04 04:08:04 -0500

updated 2016-03-04 04:20:17 -0500

Having let the default reporting tolerance (a very low value of 0.2C), I was getting a lot of unmet cooling hours.

After investigation, the ZoneHVAC equipment (ZoneHVAC:WaterToAirHeatPump) is producing a space temperature that is constantly roughly 0.5C above setpoint.

This is reported in Detailed timestep for a week in July:

Temperature versus cooling setpoint

For my ZoneHVAC:WaterToAirHeatPump I've set an Availability schedule of Always 1, and for the Supply Air Fan Operating Mode Schedule to Always 0, meaning I want a cycling fan that will turn on only as needed to meet the load. From the doc:

Schedule values of 0 denote that the supply air fan and the heating or cooling coil cycle on and off together to meet the heating or cooling load (a.k.a. AUTO fan)

What is causing my space temperature to be constantly about 0.5C above the setpoint? How can I correct this?

(I know I can just increase the reporting tolerance to let the unmet hours go away but I'm interested in finding out why that's happening)

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2016-03-04 04:28:06 -0500

I initially thought it could be two things:

  • Either this is just due to the Building's Temperature Converge Tolerance Value that has a default of 0.4C
    • Lowering that temperature to 0.2C didn't change anything
  • Or this may be a very similar issue as the one I posted here and where it was rightfully pointed out to me that this was because of the AvailabilityManager:NightCycle reporting tolerance of 1C by default. I'm thinking having set the Supply Air Fan schedule to always 0 might be triggering some built in availability manager with a hardcoded tolerance of 1C
    • Setting an Always 1 schedule for the supply air fan didn't help either

Then I realized it was something else entirely. I actually have a DOAS supplying unconditioned air to the zone as well. I've created all my systems (DOAS and ZoneHVAC) by using the OpenStudio API. Turns out I have assigned the ZoneHVAC component to the zone before I assigned the DOAS's AirTerminalUnit (ATU). As OpenStudio will generate the cooling and heating priorities based on this specific order (as pointed out on unmethours and on uservoice), my ZoneHVAC had a priority of 1 and the DOAS 2, the exact opposite as what you need to do.

From there I had two solutions: either assign the equipment to the zone in the right order, or just use setCoolingPriority and setHeatingPriority (see SDK Doc)

Here's a ruby example of the second method:

# I've already added the ZoneHVAC equipment, now I add the DOAS ATU
atu = OpenStudio::Model::AirTerminalSingleDuctUncontrolled.new(model, model.alwaysOnDiscreteSchedule)

# I could just have created this terminal BEFORE creating the other and it would have ended as first priority for cooling and heating
# But I'll set it after the fact as a good reminded that OS will by default use whatever order equipment to create the ZoneHVAC:EquipmentList
# You should always have the least controlled equipment (DOAS, etc) first in line, to let the most controlled one pickup the remaining load
zone.setCoolingPriority(atu, 1)
zone.setHeatingPriority(atu, 1)
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

 

Question Tools

2 followers

Stats

Asked: 2016-03-04 04:08:04 -0500

Seen: 131 times

Last updated: Mar 04 '16