COPs too high? -- All chilllers? (CR #5781) #763
Labels
Defect
Includes code to repair a defect in EnergyPlus
SeverityMedium
This defect is medium severity, indicating moderate impact and generally no workaround available
Added on 2003-05-02 07:56 by @lklawrie
Description
Email from Fred B after brief look at the problem:
Analysis from Don Shirey:
I looked at the 5ZoneWarmest file. I see extremely large COPs when I run a summer design day, ranging from 45 in the morning to just over 8 in the heat of the day. The nominal chiller COP is 3.2.
Assuming the equations in SUBROUTINE CalcElectricChillerModel are correct, the curve coefficients may be wrong. The coefficients are (same for this example file and the EngineDrivenChiller example file):
In SUBROUTINE CalcElectricChillerModel, the following equations are pertinent:
(starting at line 834 in file PlantChillers.f90)
!Calculate chiller performance from this set of performance equations.
! from BLAST...Z=(TECONDW-ADJTC(1))/ADJTC(2)-(TLCHLRW-ADJTC(3))
DeltaTemp= (TempCondIn - TempCondInDesign) / TempRiseRat &
- (TempEvapOut - TempEvapOutDesign)
For (FlowLock == 1) things are calculated slightly differently.
But anyway, for a typical morning hour the condenser water is coming back fairly cool (about 21C).
Following through the calculations:
DeltaTemp = -5.55 C
AvailNomCapRat = 1.2083
AvailChillerCap = 36976
FullLoadPowerRat = 0.84
PartLoadRat = 0.203
FracFullLoadPower = 0.184
Qevaporator = 7518
Power = 363
So, COP = Qevaporator / Power = 20.7!!!!
Qevaporator of 7518 matches MyLoad, which is the load to be met. However, the POWER equation is either wrong or the input coefficients to the various equations are wrong.
And further analysis (Don Shirey)
OK, I believe the equation is wrong. We had a similar issue with DX coil a while back, which is why I changed the part-load input curve for the DX coil from the original DOE-2 method.
The curve FracFullLoadPower already takes into account the part load of the chiller (i.e. the ratio of actual load to full load capacity).
In the POWER calculation, you need to multiply by AvailNomCap instead of QEvaporator. Basically, we're accounting for part load ratio (runtime) twice: once by multiplying AvailNomCap by PartLoadRat, and a second time in FracFullLoadPower which already accounts for PartLoadRat.
This is being done in all chillers...................
When I make the change that I described below, I see COPs of 3.3 at low part-loads to 4.3 on the summer design day. I'm not sure its the "FINAL" answer (maybe there are other problems lurking), but it fixes a major issue........
MJW 25Aug2003
The major issue related to chiller COP is fixed, but there still seems to be a problem with the example files producing COPs consistently higher than nominal. See CR 5945 for followup.
Fix
See description for analysis and fix, also shown below.
Not hearing back from anyone overnight, and spending another few hours on this, I've convinced myself that I've made the correct changes to all chillers except ConstantCOP (correction is not applicable to ConstantCOP chiller). However, someone familiar with the BLAST chiller models needs to check the original BLAST code/documentation to confirm what I have changed.
Originally method:
New method:
For the test file 5ZoneWarmest run on a summer design day with nominal chiller COP of 3.2, I'm now getting COPs of 3.3 to 4.3 (instead of 8 to 45). The new higher COPs (higher than the nominal 3.2) are due to low chiller condenser water inlet temps (21C vs 35C design), and also high chiller evaporator water inlet temps (20-22C vs a more reasonable 15C). The high chiller evap water inlet temps still both me --> yes this is a "variable flow" chiller with "intermittent" pump, but the inlet water temps seem unreasonably high (Rich L --> you may want to take another look at this).
External Ref: Steve Konopacki, SJKonopacki@lbl.gov -- started the ball rolling
Addressed in
03.05.01 V1.1.0.019
by @lklawrieLast build tested:
03.08.22 V1.1.1.007
The text was updated successfully, but these errors were encountered: