search

kbenne / cbecc

Automatically exported from code.google.com/p/cbecc
0 stars 0 forks source link

Night Cycle Control #862

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I am testing a model in a hot climate zone (CZ 15, Palm Springs).

The model is based on the 5 space 'SmallOffice' building, but all spaces are 
aggregated into one zone. The one system is SZVAVAC, but I have pegged 
Fan/TrmlUnit min flows to be equal to design flows, making it essentially a CV 
system. 

I am seeing issues with cooling UMLHs. Inspecting hourly reports, I am seeing 
the zone is overheating in early morning hours prior to the HVAC Availability 
schedule being ON, particularly on Sat/Sun when the avail hours extend farther 
into mid-morning.

1) The system is not night-cycling as I expected to meet the cooling Tstat 
set-back temp (85F, 29.4C). I experimented with a number of things and found 
that for AirTerminal:SingleZone:NoReheat, the AM:NightCycle is not overriding.  
If I remove the terminal availability schedule, the system will night cycle.  
Is this expected, or a bug?

2) Once I get the system to night-cycle, I see that it is providing outside air 
when it night cycles, despite the Controller:OutdoorAir, Minimum Outdoor Air 
Schedule Name.  I also set a Maximum Fraction of Outdoor Air Schedule Name, but 
this does not help. Are these OA control issues related to the Heat Recovery 
Bypass Control Type bug?

3) Even with the system night-cycling, the system still does not control for 
clg UMLHs. I am seeing that the fan turns ON, but the cooling coil output is 
not reducing the SAT to meet the load. The coil availability schedule is 
'Always On', so it is not clear why the system will not engage the cooling coil 
to meet the load when the system night cycles. I experimented with decreasing 
the AM:NightCycle, Thermostat Tolerance to 0.1C. This increase the amount of 
hours the fan night-cycles, but still does not cause the system to operate the 
cooling coil to control the zone temperature.

Original issue reported on code.google.com by da...@360-analytics.com on 1 Dec 2014 at 1:39

GoogleCodeExporter commented 9 years ago 
Files attached, as well as images showing behavior when FanIsNotNightCycling 
(item 1), as well as behavior when FanIsNightCycling (items 2 and 3). Probably 
best to schedule a quick coordination call to describe what I have/have not 
looked at.

I don't think this is a capacity issue, since as as soon as the system is no 
longer night-cycling, the design cooling setpoint (75F) can be met.

Original comment by da...@360-analytics.com on 1 Dec 2014 at 1:54

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey Kyle,
Do you think you will have some time available this week to review this issue? 

One other question that Supriya at PNNL brought up, and that is if there is an 
availability schedule defined for an AirTerminal:SingleDuct:ParallelPIU:Reheat 
or AirTerminal:SingleDuct:SeriesPIU:Reheat, will AM:NightCycle override and 
allow the terminal and terminal fan operate?  

Let me know if you have any insight you can readily share on the do's & don'ts 
of AM:NightCycle. We'll also be doing some testing internally.

Original comment by da...@360-analytics.com on 2 Dec 2014 at 11:29

GoogleCodeExporter commented 9 years ago 
Initial testing indicates for AirTerminal:SingleDuct:ParallelPIU:Reheat, if an 
AirTerminal:AvailabilitySchedule is defined, neither the system or zone fans 
will night cycle if control type = CycleOnAny or CycleOnAnyZoneFansOnly. Next I 
am testing defining the availabilty schedule at the terminal fan instead of the 
AirTerminal.  Should have that result shortly.

Original comment by da...@360-analytics.com on 3 Dec 2014 at 12:28

GoogleCodeExporter commented 9 years ago 
Moving the availability schedule from the AirTerminal to the terminal fan does 
seem to allow the system to properly night cycle. Here are pictures of the 
parallel zone fan power for a zone in a very cold climate (USA_AK_Eielson)

FanIsNotNightCycling - This is what is observed if availability schedule is 
assigned to terminal

FanIsNightCycling - This is what is observed if availability schedule is 
assigned to terminal fan

Kyle, I think we need a translator update.  My suggested plan to is to add a 
Fan:AvailSchRef property to better manage this in simulations. The current 
translation rules can remain in place, but add code that allows this property 
to override the current rules. For transparency, I will add rules to default 
this property from the Air/ZnSys level.

Original comment by da...@360-analytics.com on 3 Dec 2014 at 12:46

Attachments:

GoogleCodeExporter commented 9 years ago 
Removing the terminal availability schedule and instead specifying availability 
only at fans resolves the night cycling issue identified in item #1). However, 
delivering when night cycling (issue identified in item #2) is still present.  
Kyle, if you have availability, can you focus on this issue?

Meeting cooling loads when night cycling (issue identified in item #3) does not 
seem to be a problem for a multizone test model I used in comment #4.  I will 
continue to test this with SZVAV and other system configurations to see if I 
can further isolate the issue.

Original comment by da...@360-analytics.com on 3 Dec 2014 at 1:29

GoogleCodeExporter commented 9 years ago 
I've created a new issue for the Fan:AvailSchRef enhancement described in 
comment #4, see issue 872.

I am seeing the same intermittent behavior of AM:NightCycle in our models as is 
noted here:
https://unmethours.com/question/1743/unmet-load-hours-linked-to-cycling-run-time
/

As noted in the post, I am also observing a shut off of the system at the end 
of each 1 hour time period for one timestep, before contiuing to run the system 
to meet the zone temperature setpoint. @Archmage indicates this is just how 
AM:NightCycle works. I've also experimented with increasing the AM Cycling Run 
Time {s}, but similar to UMH post, this does not mitigate the system shut-off 
each hour.

The AM:NightCycle is not that big of an issue to T24 compliance since the 
current UMLH criteria is based on occupied hours. However, the combination of 
this behavior with introducing OA when night cycling is an issue that should be 
addressed.

We are setting Controller:OutdoorAir, Minimum Outdoor Air Schedule Name, and 
this was assumed to mitigate introducing OA during night cycle. I am testing 
other combinations of inputs, but if others on this issue know of the correct 
specification of schedules to ensure OA dampers are closed during night cycle, 
that information is welcomed.

Original comment by da...@360-analytics.com on 9 Dec 2014 at 5:51

GoogleCodeExporter commented 9 years ago 
Re "2) Once I get the system to night-cycle, I see that it is providing outside 
air when it night cycles, despite the Controller:OutdoorAir, Minimum Outdoor 
Air Schedule Name.  I also set a Maximum Fraction of Outdoor Air Schedule Name, 
but this does not help. Are these OA control issues related to the Heat 
Recovery Bypass Control Type bug?"

I am surprised that the max fraction is not working.  I wonder if the problem 
stems from the presence of the min schedule conflicting with the max fraction.  
You said you tried using a max fraction schedule, but did you leave the min 
schedule in place?  I don't recall what we are trying to achieve with the min 
schedule, but I assume it is to turn off the ventilation at off hours.  I think 
I may have moved in this direction in error.  I think we should be using the 
max fraction exclusively for this case.  That is what I laid out in my email to 
Mike.  See examples here where it is working. 
https://drive.google.com/folderview?id=0B6AYyX2ggNyBRW9SUmJWN0ZIcWc&usp=sharing&
tid=0B6AYyX2ggNyBajM5a29JYTlyNnM

Original comment by kbe...@gmail.com on 10 Dec 2014 at 6:47

GoogleCodeExporter commented 9 years ago 
This seems to work as I would expect.  Do you agree?  We do have handles for 
"MinOAFracSchRef" and "MaxOAFracSchRef".  I suggest we use the MaxOAFracSchRef 
for this use case where we want to turn off ventilation.  

Controller:OutdoorAir,
  CoreZnOAControl,                        !- Name
  CoreZnOAControl OA System Relief Node,  !- Relief Air Outlet Node Name
  CoreZnPSZ AirSys Supply Side (Return Air) Inlet Node, !- Return Air Node Name
  CoreZnOAControl OA System Mixed Air Node, !- Mixed Air Node Name
  CoreZnOAControl OA System OA Node,      !- Actuator Node Name
  Autosize,                               !- Minimum Outdoor Air Flow Rate {m3/s}
  Autosize,                               !- Maximum Outdoor Air Flow Rate {m3/s}
  NoEconomizer,                           !- Economizer Control Type
  ModulateFlow,                           !- Economizer Control Action Type
  ,                                       !- Economizer Maximum Limit Dry-Bulb Temperature {C}
  64000,                                  !- Economizer Maximum Limit Enthalpy {J/kg}
  ,                                       !- Economizer Maximum Limit Dewpoint Temperature {C}
  ,                                       !- Electronic Enthalpy Limit Curve Name
  ,                                       !- Economizer Minimum Limit Dry-Bulb Temperature {C}
  NoLockout,                              !- Lockout Type
  FixedMinimum,                           !- Minimum Limit Type
  ,               !- Minimum Outdoor Air Schedule Name
  ,                                       !- Minimum Fraction of Outdoor Air Schedule Name
  CoreZnOAControl Schedule,                                       !- Maximum Fraction of Outdoor Air Schedule Name
  CoreZnOAControl Mech Vent Controller,   !- Mechanical Ventilation Controller Name
  ,                                       !- Time of Day Economizer Control Schedule Name
  No,                                     !- High Humidity Control
  ,                                       !- Humidistat Control Zone Name
  ,                                       !- High Humidity Outdoor Air Flow Ratio
  Yes,                                    !- Control High Indoor Humidity Based on Outdoor Humidity Ratio
  BypassWhenOAFlowGreaterThanMinimum;     !- Heat Recovery Bypass Control Type

Original comment by kbe...@gmail.com on 10 Dec 2014 at 7:14

Attachments:

GoogleCodeExporter commented 9 years ago 
David, try using the 'Minimum OA Schedule Name' object and set it to be 
unavailable during occupied hours. I remember having looked into this before 
and found the same issue- max fraction OA schedule name doesn't prevent OA 
intake during unoccupied hours. I'll dig through my notes and get back to you 
on that.

Original comment by supriya....@pnnl.gov on 10 Dec 2014 at 7:42

GoogleCodeExporter commented 9 years ago 
Thanks KB and SG for looking into this. 

KB, I am testing your recommendation, will get back to you on what I find. 

SG, we are setting a Minimum Outdoor Air Schedule Name, but once I got night 
cycling to occur, I see that schedule doesn't actually limit the OA during 
occupied hours (as the I/O ref suggests), at least not when combined with a 
Maximum Fraction of Outdoor Air Schedule Name (set to 1.0 for all hours).

Should have some additional testing to share in a few hours.

Original comment by da...@360-analytics.com on 10 Dec 2014 at 7:55

GoogleCodeExporter commented 9 years ago 
Supriya,

CBECC has been setting min oa schedule, but it is not working and I believe it 
is incorrect for OS type idf files.  I believe max fraction does work as shown 
in #8.  I have been advocating this method for all OpenStudio models because I 
believe it is the most fool proof way to turn off ventilation in off hours.  I 
have test cases to support this position here, 
https://drive.google.com/folderview?id=0B6AYyX2ggNyBRW9SUmJWN0ZIcWc&usp=sharing&
tid=0B6AYyX2ggNyBajM5a29JYTlyNnM.  And also the example model David uploaded 
with the oa controller setup per #8. I admit there are many variable involved 
though, so this guidance may not be 100% foolproof.  I am interested in any 
examples you have where max fraction schedule is not working on an OS model.

Original comment by kbe...@gmail.com on 10 Dec 2014 at 8:41

GoogleCodeExporter commented 9 years ago 
I created a derivative of the 90.1 ruleset MedOffice test model. The 
fundamental change was to remove the AirTerminal availability schedule, and 
specify availability schedules at all fans, including PIUs. This particular 
model has 3 floors of office, one PVAV system per floor, with electric parallel 
PIUs serving each zone; systems have diff DB economizers. 

I created 3 derivatives of this model:

1) MinOA+MaxFracOA: Includes a Minimum Outdoor Air Schedule Name that is 0 
during unoccupied hours, 1 during occupied, and a Maximum Fraction of Outdoor 
Air Schedule Name that is 1 for all hours

2) MinOA: Include only a Minimum Outdoor Air Schedule Name that is 0 during 
unoccupied hours, 1 during occupied; no MaxFracOA schedule.

3) MaxFracOA: Include only a Maximum Fraction of Outdoor Air Schedule Name that 
is 0 during unoccupied hours, 1 during occupied; no MinOA schedule.

None of these combinations seems to limit OA during night cycle. I tested with 
hot (Palm Springs) EPW, though I also tested #2 and #3 with a cold climate 
(Mount Shasta).  

Kyle, one thing I did note was the current Minimum Outdoor Air Schedule Name 
you are creating from our SDD inputs is an OnOff schedule, as opposed to a 
Fraction schedule. I tested changing to a Fraction schedule in the MinOAFixed 
version, but the results did not change. Also, not sure if this is important, 
but the Heat Recovery Bypass Control Type used in the comment #1 example is 
BypassWhenOAFlowGreaterThanMinimum (this is the exception for SZVAV).  In the 
attached examples and most SDD models, we use BypassWhenWithinEconomizerLimits. 
However, I tested a version of with the older spec (MaxFracOA2), and didn't see 
any change. 

Kyle, perhaps look at the MaxOAFrac model first to make sure I am not missing 
anything.

Original comment by da...@360-analytics.com on 11 Dec 2014 at 12:17

Attachments:

GoogleCodeExporter commented 9 years ago 
OK disregard my comments #8 and #11.  I overlooked key hours when the system is 
running, ventilation should be off, but it is not.  You guys must have been 
like wtf model is he looking at.  So I simplified the model.  Took out the 
pesky exhaust fan.  Those are always suspect when dealing with issues of OA.  
Took out the night cycle manager and just used a scheduled manager.  Made the 
RestaurantHVACAvail always on.  guess what.  ventilation is always on too.  
tried removing the mech ventilation controller.  I have taken heat for leaving 
that in when not trying to night cycle.  Still not helping.  So I'm very 
confused.  Why is my example model that I linked to on gdrive working?  What 
makes this model different.  One thing is that it has more simple direct air 
terminals.  I'm going to look into that in the morning.  Retiring for now.

Original comment by kbe...@gmail.com on 11 Dec 2014 at 5:35

GoogleCodeExporter commented 9 years ago 
My proposed fix is here.  
https://github.com/NREL/OpenStudio/commit/07d89e00b79fb7439046749009f37d17983827
f3

Original comment by kbe...@gmail.com on 15 Dec 2014 at 7:19

GoogleCodeExporter commented 9 years ago 
I reviewed the most recent OS updates. The updates fix the issues identified 
here

- Removed setting TrmlUnit:AvailSchRef in SDD models.  This was inhibiting 
AirSystems from night cycling.
- The OS translator now sets the Fan availability schedule for all system fans, 
including fan powered-boxes (supply/return/relief already were being set). 
Translation of SDD property Fan:AvailSchRef has been added, but this is 
currently not used since the OS defaulting is working.
- The OS IDF forward translator now sets the 
ControllerMechanicalVentilation::AvailabilitySchedule to be the same as 
ControllerOutdoorAir::minimumOutdoorAirSchedule, if specified. This inhibits 
CMV from overriding the min OA schedule if the CMV schedule value is 0. If the 
CMV schedule value is > 0, CMV overrides the min OA schedule.

Attached is a plot illustrating night cycling with the OA set to minimum.  The 
controller still modulates OA to not exceed the system maximum reset 
temperature, currently 60F.

Closing issue

Original comment by da...@360-analytics.com on 27 Dec 2014 at 8:55

Attachments: