search

kbenne / cbecc

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

ZoneHVAC WSHP simulation review #940

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Describe the translation issue or enhancement:
Issue 903 prompted a closer look at WSHP simulation errors and results. Here 
are findings from that review:

1) The built in WaterToAirHeatPump:EquationFit curves result in the following 
error:
** Warning ** COIL:COOLING:WATERTOAIRHEATPUMP:EQUATIONFIT "CORE CLGCOIL"
   **   ~~~   ** SizeWaterToAirCoil: Rated Sensible Cooling Capacity > Rated Total Cooling Capacity
   **   ~~~   ** Each of these capacity inputs have been autosized.
   **   ~~~   ** Rated Sensible Cooling Capacity = 89782.85 W
   **   ~~~   ** Rated Total Cooling Capacity    = 55285.51 W
   **   ~~~   ** See eio file for further details.
   **   ~~~   ** Check Total and Sensible Cooling Capacity Coefficients to ensure they are accurate.
   **   ~~~   ** Check Zone and System Sizing objects to verify sizing inputs.
   **   ~~~   ** Sizing statistics:
   **   ~~~   ** Entering Air Dry-Bulb Temperature = 27.321 C
   **   ~~~   ** Entering Air Wet-Bulb Temperature = 17.961 C
   **   ~~~   ** Entering Condenser Water Temperature used = 24.4444 C
   **   ~~~   ** Used design air and water flow rates (i.e., used 1 for ratioVL and ratioVS)
   **   ~~~   ** ratioTDB = 1.136
   **   ~~~   ** ratioTWB = 1.102
   **   ~~~   ** ratioTS  = 1.347
   **   ~~~   ** Sensible Cooling Capacity Modifier = 0.49689
   **   ~~~   ** ...Rated Sensible Cooling Capacity = Sensible Design Load / Sensible Cooling Capacity Modifier
   **   ~~~   ** Total Cooling Capacity Modifier = 0.39897
   **   ~~~   ** ...Rated Total Cooling Capacity = Total Design Load / Total Cooling Capacity Modifier
   **   ~~~   ** Carefully review the Load Side Total, Sensible, and Latent heat transfer rates
   **   ~~~   ** ... to ensure they meet the expected manufacturers performance specifications.

To address this, I decided to look at the curves, since the only thing we are 
autosizing is the sensible capacity. I reviewed the E+ example file curves, and 
found the CBECC-Com default curves match those in the E+ 
HeatPumpWaterToAirEquationFit.idf example file.  One thing to note is this file 
does not have the error above, but the coil capacities are all hard-sized. I 
looked at a few other E+ examples, and found a different set of curves in the 
ZoneWSHP_wDOAS.idf and HospitalLowEnergy.idf models (see attachment with curves 
from all three models). I tried these curves and found it eliminated this 
error, the autosized SHRs seem reasonable. Comparing the CW loop loads 
associated with the two different sets of curves, I find our current curves 
result in some very high condenser loads during shoulder months that I cannot 
explain without more digging. Therefore, I recommend we switch to this 
alternate set of curves, which requires an OS update.

2) The temperature of the CW loop is not being maintained within it's 
setpoints. Not sure what the reason is, but if I tighten the control temp band 
by ~2.5C (by changing the upper and lower SPM setpoints), I see a corresponding 
change in the CW loop supply temperatures.  This indicates it is not a primary 
equipment capacity issue, but a control issue.  Is there some sort of building 
throttling range for the scheduled controller?  

3) The CW pump head is not being correctly translated. The pump head in the 
attached model is 20ft (59781 Pa). In the final IDF, the pump head is ~26ft 
(79782 Pa).

4) HtPumpEIR not being translated to Gross Rated Heating COP

5) For Coil:Cooling:WaterToAirHeatPump:EquationFit, the !- Rated Water Flow 
Rate {m3/s} is hard sized, while for 
Coil:Heating:WaterToAirHeatPump:EquationFit. Is there a rationale for this 
difference in approach?

5) The ZnSys:FanCtrl = 'Continuous', however, looking at the hourly results it 
is clear the ZoneHVAC system is cycling to meet loads.

What version of OpenStudio are you using? On what operating system?
CBECC-Com v3b beta r3057

Attachements:
a) A modified WSHP model that only has one ZnSys for the building.  INcludes 
the original - ap model and the idfs for additional runs (diff to see what 
changed)
b) WaterToAirHeatPump:EquationFit curves from the E+ example models

Original issue reported on code.google.com by da...@360-analytics.com on 15 Feb 2015 at 10:51

Attachments:

GoogleCodeExporter commented 9 years ago 
OK.

Original comment by kbe...@gmail.com on 17 Feb 2015 at 6:47

GoogleCodeExporter commented 9 years ago 
HeatPumpWaterToAirEquationFit.idf uses the heat pump coils in the context of 
AirLoopHVAC system.  This is the file that uses the curves we currently have.  
ZoneWSHP_wDOAS.idf uses the heat pump in zone hvac, so maybe the example files 
are trying to capture the distinction with different curves.  

In CBECC we used the same curves regardless of context.  Here we are moving to 
zone hvac example curves which will now be used in all WSHP including 
AirLoopHVAC.  I'm fine with all of this.  Just saying...

Original comment by kbe...@gmail.com on 17 Feb 2015 at 10:09

GoogleCodeExporter commented 9 years ago 
RE: 4) The translator is looking for HtPumpCOP.  Should I keep that and also 
support HtPumpEIR doing necessary conversion?  Or something else?

Original comment by kbe...@gmail.com on 17 Feb 2015 at 10:35

GoogleCodeExporter commented 9 years ago 
RE: 1) 
https://github.com/NREL/OpenStudio/commit/a154a685227113458195aa2b0b27f5a4ebd2a2
9f

Original comment by kbe...@gmail.com on 17 Feb 2015 at 10:37

GoogleCodeExporter commented 9 years ago 
RE: 3) oh after reviewing the code, I remember this little gem.  Refer to these 
lines in the translator 
https://github.com/NREL/OpenStudio/blob/CBECC/openstudiocore/src/sdd/MapHVAC.cpp
#L5012.  It is only using TotHd if the model is autosized.  Otherwise the head 
is defined by the flow min, cap, and power specification to avoid being over 
constrained. The simulation will fail if you have inconsistently over 
constrained the inputs.

How do you want to proceed?

Original comment by kbe...@gmail.com on 17 Feb 2015 at 10:50

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Re #3), we should be using HtPumpEIR for both water- and air-source heat pump 
coils.  EnergyPlus COP = 1/HtPumpEIR.

Let me know if the translator is not looking for HtPumpEIR for air-source 
coils.  If so, this was an oversight on my part from a while ago.

Original comment by da...@360-analytics.com on 17 Feb 2015 at 10:54

GoogleCodeExporter commented 9 years ago 
By #3, I meant comment #3, not item 3) of issue.  I will make clearer in 
subsequent posts.

Original comment by da...@360-analytics.com on 17 Feb 2015 at 10:55

GoogleCodeExporter commented 9 years ago 
RE: 6) Ok we are using the unitary system which could support cycling / 
continuous operation, but that is a little effort that has not been made yet.  
Why don't we push that out after the release?

Original comment by kbe...@gmail.com on 17 Feb 2015 at 10:57

GoogleCodeExporter commented 9 years ago 
RE: #5) Rated water flow rate comes from FluidFlowRtDsgnSim and it appears the 
example model has this property for the cooling coil, but not the heating coil.

Original comment by kbe...@gmail.com on 17 Feb 2015 at 10:58

GoogleCodeExporter commented 9 years ago 
The air source pumps are defining EIR as you specified.  I will add the same to 
water source.

Original comment by kbe...@gmail.com on 17 Feb 2015 at 11:02

GoogleCodeExporter commented 9 years ago 
RE EIR  
https://github.com/NREL/OpenStudio/commit/89fe46608daf6b35dff0e764f11fc3bfac30d5
89

Original comment by kbe...@gmail.com on 17 Feb 2015 at 11:08

GoogleCodeExporter commented 9 years ago 
Alright thats it from me for now.  Unless I hear something about 
FluidFlowRtDsgnSim or the TotHd issue.

Original comment by kbe...@gmail.com on 17 Feb 2015 at 11:10

GoogleCodeExporter commented 9 years ago 
Re: Comment #5, thanks for pointing this out.  I recall the potential 
inconsistency issues, but I don't recall the workaround. I think this is OK. 
The static assumption of combined pump/motor efficiency of 0.80 is high, hence 
why the calculated pump head is high as well. In any case, I recommend we leave 
this as is for now.

Original comment by da...@360-analytics.com on 17 Feb 2015 at 11:17

GoogleCodeExporter commented 9 years ago 
Re: comment #2/9, The system I see in the idf of this model is 
ZoneHVAC:WaterToAirHeatPump. I seem to recall we could not readily support 
water-source coils in AirLoopHVAC, and that implementation using the Unitary 
object was shelved. 

In the context of using ZoneHVAC, according the I/O ref, continuous vs cycling 
is managed by Field: Supply Air Fan Operating Mode Schedule Name. I didn't see 
this in the idf file; does OS have an element to manage this?

Original comment by da...@360-analytics.com on 17 Feb 2015 at 11:37

GoogleCodeExporter commented 9 years ago 
Re: comment #10, issue 603 documents the initial implementation of these 
systems, and it seems to indicate it was found the flow rate was needed for the 
cooling coil but not necessarily the heating coil. Sounds like if we specify 
CoilHtg:FluidFlowRtDsgnSim, it will be translated, so we can test on our own.  
Thanks for looking into this.

Original comment by da...@360-analytics.com on 17 Feb 2015 at 11:40

GoogleCodeExporter commented 9 years ago 
Since we have some time, I'd like to ask to address in the translator one more 
outstanding issue: When ZnSys:FanCtrl = 'Continuous', the ZoneHVAC system is 
still cycling to meet loads.

I think this can be addressed by specifying Field: Supply Air Fan Operating 
Mode Schedule Name in the idf file.

The translation would be:
If ZnSys:FanCtrl = 'Continuous', the assigned schedule should be the same as 
the system Availability Schedule Name
If ZnSys:FanCtrl = 'Cycling', the field should be left blank, or assigned a new 
schedule with values of 0.

Original comment by da...@360-analytics.com on 4 Mar 2015 at 8:05

GoogleCodeExporter commented 9 years ago 
Re: #17 If Continuous how about we just use always on schedule?  The 
availability schedule will still turn the entire system on and off.

Is this something (cycling fan) we need to think about for AirLoopHVAC systems?

Original comment by kbe...@gmail.com on 6 Mar 2015 at 7:17

GoogleCodeExporter commented 9 years ago 
Here is cycling fan for WSHP.  I don't know why i thought this was a big deal.  
I guess if we need it for AirLoopHVAC based systems it might be more thinking.

https://github.com/NREL/OpenStudio/commit/0bf6fff25d12ef48b25c7fb5d5d1e80a6adf23
f7

Original comment by kbe...@gmail.com on 6 Mar 2015 at 9:28

GoogleCodeExporter commented 9 years ago 
I don't think we need it for air loop systems.  For zone systems, they can 
cycle while ventilation is provided by an air system DOAS.

Original comment by rhedr...@archenergy.com on 6 Mar 2015 at 9:33

GoogleCodeExporter commented 9 years ago 
Re: comment #18, AlwaysOn works provided the Fan:AvailabiltySchedule overrides 
this schedule.

Re: comment #19, cycling fans for AirLoopHVAC based systems would be great, but 
I seem to straight-forward. Thinking about this more, wouldn't this just be 
Fan:AvailabilitySchedule set to AlwaysOff, and use an 
AvailabilityManager:NightCycle?  We don't allow AirSystems to operate 
intermittantly if they are the ventilation system, but otherwise, yes, they 
could be cycling.

Original comment by da...@360-analytics.com on 6 Mar 2015 at 9:38

GoogleCodeExporter commented 9 years ago 
Nice idea. Night cycle with no thermostat offset could be used to cycle.  I've 
never heard of anyone using that approach, but it is a pretty good idea i 
think.  The conventional approach is to put the fan and coils in a unitary 
system, but we aren't using them except for the water to air heat pump coils 
and then we only put the coil inside the unitary.  It seems you understand this 
and understand why I say cycling would take more work for air based systems.  
... Unless you use the night cycle idea.  For now it seems like my #19 commit 
will provide what you need.

Original comment by kbe...@gmail.com on 6 Mar 2015 at 9:54