Variable flow condenser plant control #10511

lymereJ · 2024-05-17T19:31:20Z

Pull request overview

Fixes Chiller always requests full condenser flow regardless of flow mode or pump type #7111
This PR intends to fix the aforementioned issue by adding options to simulate variable flow condenser plant control for selected chiller models. This PR includes changes to the Chiller:Electric:EIR and Chiller:Electric:ReformulatedEIR, the same changes to the Chiller:Electric:ASHRAE205 will be included in a later PR.

NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
If any diffs are expected, author must demonstrate they are justified using plots and descriptions
If structural output changes, add to output rules file and add OutputChange label

Reviewer

This will not be exhaustively relevant to every PR.

…or dT.

EnergyArchmage · 2024-06-12T13:12:25Z

src/EnergyPlus/ChillerElectricEIR.cc

+            this->CondMassFlowRate = this->CondMassFlowRateMax;
+        } break;
+        case DataPlant::CondenserFlowControl::ModulatedChillerPLR: {
+            this->CondMassFlowRate = this->CondMassFlowRateMax * PartLoadRat;


Might be out of scope for you, but in my custom version I add in limit for what the variable speed pump can actually do for a minimum. Could be a loop pump or a branch pump on this chiller.

Here is how I have this bit coded in custom version

if (this->VSBranchPumpFoundCond) { // TRANE if (MyLoad < 0.0 && RunFlag) { // TRANE this->CondMassFlowRate = this->CondMassFlowRateMax * std::max(PartLoadRat, this->MinPartLoadRat); // TRANE this->CondMassFlowRate = std::max(this->CondMassFlowRate, this->VSBranchPumpMinLimitMassFlowCond); // TRANE } else { // TRANE this->CondMassFlowRate = 0.0; // TRANE } // TRANE } else if (this->VSLoopPumpFoundCond) { // TRANE if (MyLoad < 0.0 && RunFlag) { // TRANE this->CondMassFlowRate = this->CondMassFlowRateMax * std::max(PartLoadRat, this->MinPartLoadRat); // TRANE } else { // TRANE this->CondMassFlowRate = 0.0; // TRANE } // TRANE } // TRANE

where branch pump limit and bools get filled like this

this->VSBranchPumpMinLimitMassFlowCond = PlantUtilities::MinFlowIfBranchHasVSPump(state, this->CDPlantLoc, this->VSBranchPumpFoundCond, this->VSLoopPumpFoundCond, false); if (this->VSLoopPumpFoundCond) { this->VSLoopPumpMinLimitMassFlowCond = this->VSBranchPumpMinLimitMassFlowCond; this->VSBranchPumpMinLimitMassFlowCond = 0.0; }

I think these pump limits would apply to all three methods.

Thanks! I have a Condenser Minimum Flow Fraction input as part of the proposed changes but I guess it couldn't hurt to make sure that the pump minimum flow rate isn't less than the flow rate calculated from the fraction, I'll add that.

lymereJ · 2024-06-13T20:00:35Z

Annual simulation results with the new control options:

ConstantFlow:

ModulatedChillerPLR:

ModulatedLoopPLR (with a CWFR = 1 * PLR curve and a minimum flow fraction of 0.35):

ModulatedDeltaTemperature (vertical bar correspond to cycling chiller operation):

lymereJ

Code changes walk-through!

lymereJ · 2024-06-13T20:33:12Z

src/EnergyPlus/ChillerElectricEIR.cc

+        // get minimum condenser plant loop pump mass flow rate
+        this->VSBranchPumpMinLimitMassFlowCond =
+            PlantUtilities::MinFlowIfBranchHasVSPump(state, this->CDPlantLoc, this->VSBranchPumpFoundCond, this->VSLoopPumpFoundCond, false);


Get minimum pump flow rate as suggested by @EnergyArchmage.

lymereJ · 2024-06-13T20:34:06Z

src/EnergyPlus/ChillerElectricEIR.cc

@@ -655,6 +655,57 @@ void GetElectricEIRChillerInput(EnergyPlusData &state)
            }
        }

+        if (NumAlphas > 16) {


Getting the new inputs.

lymereJ · 2024-06-13T20:35:27Z

src/EnergyPlus/ChillerElectricEIR.cc

@@ -1470,7 +1524,7 @@ void ElectricEIRChillerSpecs::size(EnergyPlusData &state)

            Real64 rho = FluidProperties::GetDensityGlycol(state,
                                                           state.dataPlnt->PlantLoop(this->CDPlantLoc.loopNum).FluidName,
-                                                           Constant::CWInitConvTemp,
+                                                           this->TempRefCondIn,


Using a chilled water seemed incorrect since we dealing with a condenser loop. Also, it was inconsistent with the Cp below.

lymereJ · 2024-06-13T20:36:32Z

src/EnergyPlus/ChillerElectricEIR.cc

+                Real64 chwLoopCap = state.dataSize->PlantSizData(PltSizNum).DesCapacity;
+                Real64 chwLoopDemand =
+                    std::abs(state.dataPlnt->PlantLoop(this->CWPlantLoc.loopNum).LoopSide(this->CWPlantLoc.loopSideNum).UpdatedDemandToLoopSetPoint);
+                Real64 cwhLoopPLR = 0.0;
+                if (chwLoopDemand > 0) {
+                    cwhLoopPLR = chwLoopDemand / chwLoopCap;
+                }


Calculation of the CWH loop PLR using the Sizing:Plant objects, an error is thrown if these objects are not included.

lymereJ · 2024-06-13T20:37:29Z

src/EnergyPlus/ChillerElectricEIR.cc

+        this->CondMassFlowRate = max(min(this->CondMassFlowRate, this->CondMassFlowRateMax),
+                                     this->MinCondFlowRatio * this->CondMassFlowRateMax,
+                                     this->VSBranchPumpMinLimitMassFlowCond);


Apply the user-specified minimum flow fraction and consider the pump minimum flow rate as well.

So this is the max of three things? I wasn't expecting that. The logic here is fine, but I wouldn't mind this broken into an intermediate variable or two. The combined min/max with multiplication in the middle makes it difficult to spot a bug. The MinCondFlowRatio * CondMassFlowRateMax could be a single variable. Then the min(.., ..) portion could be a single named variable. Then the max of all three would be clear. This would be a nice change.

lymereJ · 2024-06-13T20:38:02Z

src/EnergyPlus/ChillerReformulatedEIR.cc

@@ -628,6 +628,57 @@ void GetElecReformEIRChillerInput(EnergyPlusData &state)
        } else {
            thisChiller.EndUseSubcategory = "General";
        }
+


Pretty much the same changes are applied to this object.

lymereJ · 2024-06-13T20:39:01Z

src/EnergyPlus/Plant/PlantManager.cc

+            if (state.dataPlnt->PlantFinalSizesOkayToReport) {
+                BaseSizer::reportSizerOutput(state, "PlantLoop", state.dataPlnt->PlantLoop(LoopNum).Name, "Design Capacity [W]", DesignPlantCapacity);
+            }


New EIO output which is useful to check the chilled water plant loop PLR used in the ModulatedLoopPLR control option.

lymereJ · 2024-06-13T20:40:15Z

src/EnergyPlus/PlantUtilities.cc

-                foundLoopPump = true;
-                if (component.CompNum > 0) branchPumpMinFlowLimit = state.dataPumps->PumpEquip(component.CompNum).MassFlowRateMin;
-                break;
+        if (state.dataPlnt->PlantLoop(plantLoc.loopNum).LoopSide(DataPlant::LoopSideLocation::Supply).TotalBranches > 1) {


Catches when there are no supply branches. I run into that issue for the unit test, I don't think this should be an issue in actual simulations...

Yeah...probably not. :)

lymereJ · 2024-06-13T20:40:54Z

tst/EnergyPlus/unit/ChillerElectricEIR.unit.cc

@@ -371,3 +371,166 @@ TEST_F(EnergyPlusFixture, ChillerElectricEIR_EvaporativelyCooled_Calculate)
    EXPECT_NEAR(6.22019725E-06, EvapCondWaterVolFlowRate, 0.000000001);
    EXPECT_NEAR(EvapCondWaterVolFlowRate, thisEIRChiller.EvapWaterConsumpRate, 0.000000001);
 }
+
+TEST_F(EnergyPlusFixture, ChillerElectricEIR_WaterCooledChillerVariableSpeedCondenser)


New tests for both chiller models that tests all three new control option as well as the minimum condenser flow fraction.

lymereJ · 2024-06-13T20:46:06Z

Diff review:

26a11b9 shows only AUD/EIO diffs which are due to the new inputs (with their defaults) and the new EIO output (PlantLoop Design Capacity [W])
c34186e includes the same diffs and others (ERR, MTR, etc...) which are all due to the simple change in that commit which I think is justified.

So all diffs are, I think, expected.

Myoldmopar

Code changes are fine. I made some comments that you can act on or not, they aren't major concerns. The one thing that does need fixed is the LaTeX errors. Let me know if you have trouble identifying them.

Myoldmopar · 2024-07-03T16:55:09Z

doc/engineering-reference/src/simulation-models-encyclopedic-reference/chillers.tex

@@ -2006,3 +2006,60 @@ \subsubsection{Chiller Basin Heater}\label{chiller-basin-heater-3}
 \emph{Schedule\(_{heater,basin}\)} is the basin heater schedule, user input (schedule value \textgreater{} 0 means ON)

 \emph{ChillerIsOFF} is the logical variable denoting that the chiller is not operating for the current simulation time step (e.g.,~ there is no cooling load to be met by the chiller, or if there is no water flow through the chiller due to a chiller or pump availability schedule, etc.). 
+
+\subsection{Variable Flow Condenser}\label{hot-water-heat-recovery-from-chillers}


This is a duplicate label causing a LaTeX warning. Give it a more meaningful label, or if you aren't going to reference it anywhere, just take off the label specification.

Myoldmopar · 2024-07-03T16:55:40Z

doc/engineering-reference/src/simulation-models-encyclopedic-reference/chillers.tex

+\({CAP_{CHWL}}\) is the design chilled water loop capacity determined using inputs from the Sizing:Plant object for the loop
+
+
+The condenser plant loop water flow fraction (\({CWFR}\)) corresponding to the \({PLR_{CWHL}}\) is obtained by feeding it through a user-specified curve. A linear curve is expected: \(CWFR = C * {PLR_{CHWL}} + D\)  where C and D are coefficients. A reference for these coefficients is provided in ``Optimizing Design & Control Of Chilled Water Plants, Part 5'', S. Taylor, ASHRAE Journal June 2012.


The & symbol needs to be escaped in this sentence, it is causing a LaTeX error.

Myoldmopar · 2024-07-03T16:56:38Z

doc/input-output-reference/src/overview/group-plant-equipment.tex

@@ -2131,6 +2148,22 @@ \subsubsection{Inputs}\label{inputs-5-021}

 This optional field allows you to specify a user-defined end-use subcategory, e.g., ``Process''. A new meter for reporting is created for each unique subcategory (ref: \hyperref[outputmeter-and-outputmetermeterfileonly]{Output:Meter} objects). Any text may be used here to further subcategorize the end-uses in the ABUPS End Uses by Subcategory table and in the LEED Summary EAp2-4/5 Performance Rating Method Compliance table. If this field is omitted or blank, the chiller will be assigned to the ``General'' end-use subcategory.

+\paragraph{Field: Condenser Flow Control}\label{field-condenser-flow-control}


This label is multiply defined, give it a variant name or just remove the label spec if you aren't going to reference it anywhere.

Myoldmopar · 2024-07-03T16:56:42Z

doc/input-output-reference/src/overview/group-plant-equipment.tex

+
+This field is optional.~ It describes the chiller condenser flow request mode to be used in a simulation. With ``ConstantFlow'' a chiller will always request its maximum condenser flow rate. With ``ModulatedChillerPLR'' the condenser flow request corresponds to the chiller part load ratio multiplied by the chiller maximum condenser flow rate.  With  ``ModulatedLoopPLR'' the chiller will request a flow rate that is function of the chilled water loop's part load ratio, see the \hyperref[field-condenser-loop-flow-rate-function-of-loop-part-load-ratio-curve-name]{Condenser Loop Flow Rate Fraction Function of Loop Part Load Ratio Curve Name} input. With ``ModulatedDeltaTemperature'' the chiller will request the flow rate required to meet a condenser loop delta temperature, see the \hyperref[field-temperature-difference-across-condenser-schedule-name]{Temperature Difference Across Condenser Schedule Name} input. Use ``ConstantFlow'' when modeling a constant flow condenser plant loop, choose one of the other inputs when modeling a variable flow condenser plant loop. The default is ``ConstantFlow''.
+
+\paragraph{Field: Condenser Loop Flow Rate Fraction Function of Loop Part Load Ratio Curve Name}\label{field-condenser-loop-flow-rate-function-of-loop-part-load-ratio-curve-name}


This label is multiply defined, give it a variant name or just remove the label spec if you aren't going to reference it anywhere.

Myoldmopar · 2024-07-03T16:56:49Z

doc/input-output-reference/src/overview/group-plant-equipment.tex

+
+This field describes the condenser loop flow rate fraction as a function of the chiller water loop part load ratio. A linear curve is expected: CWFR = C * PLR + D where CWFR is the condenser water flow fraction (actual/design), PLR is the chilled water plant loop part load ratio (actual/design), and C and D are coefficients. A reference for these coefficients is provided in ``Optimizing Design & Control Of Chilled Water Plants, Part 5'', S. Taylor, ASHRAE Journal June 2012.  This input is only used when the ``ModulatedLoopPLR'' condenser flow control option is used.
+
+\paragraph{Field: Temperature Difference Across Condenser Schedule Name}\label{field-temperature-difference-across-condenser-schedule-name}


This label is multiply defined, give it a variant name or just remove the label spec if you aren't going to reference it anywhere.

Myoldmopar · 2024-07-03T17:03:01Z

src/EnergyPlus/ChillerElectricEIR.cc

+            thisChiller.MinCondFlowRatio = state.dataIPShortCut->rNumericArgs(19);
+        } else {
+            thisChiller.MinCondFlowRatio = 0.2;
+        }


Several more of these could be simplified if the default value was just assigned on the variable at the class definition. Not necessary, but you could end up with 10-15 lines removed just from that change.

Myoldmopar · 2024-07-03T17:03:34Z

src/EnergyPlus/ChillerElectricEIR.cc

@@ -1470,7 +1524,7 @@ void ElectricEIRChillerSpecs::size(EnergyPlusData &state)

            Real64 rho = FluidProperties::GetDensityGlycol(state,
                                                           state.dataPlnt->PlantLoop(this->CDPlantLoc.loopNum).FluidName,
-                                                           Constant::CWInitConvTemp,
+                                                           this->TempRefCondIn,


Myoldmopar · 2024-07-03T17:03:37Z

src/EnergyPlus/ChillerElectricEIR.cc

+        // get minimum condenser plant loop pump mass flow rate
+        this->VSBranchPumpMinLimitMassFlowCond =
+            PlantUtilities::MinFlowIfBranchHasVSPump(state, this->CDPlantLoc, this->VSBranchPumpFoundCond, this->VSLoopPumpFoundCond, false);


Myoldmopar · 2024-07-03T17:08:09Z

src/EnergyPlus/ChillerElectricEIR.cc

+        this->CondMassFlowRate = max(min(this->CondMassFlowRate, this->CondMassFlowRateMax),
+                                     this->MinCondFlowRatio * this->CondMassFlowRateMax,
+                                     this->VSBranchPumpMinLimitMassFlowCond);


So this is the max of three things? I wasn't expecting that. The logic here is fine, but I wouldn't mind this broken into an intermediate variable or two. The combined min/max with multiplication in the middle makes it difficult to spot a bug. The MinCondFlowRatio * CondMassFlowRateMax could be a single variable. Then the min(.., ..) portion could be a single named variable. Then the max of all three would be clear. This would be a nice change.

Myoldmopar · 2024-07-03T17:09:20Z

src/EnergyPlus/PlantUtilities.cc

-                foundLoopPump = true;
-                if (component.CompNum > 0) branchPumpMinFlowLimit = state.dataPumps->PumpEquip(component.CompNum).MassFlowRateMin;
-                break;
+        if (state.dataPlnt->PlantLoop(plantLoc.loopNum).LoopSide(DataPlant::LoopSideLocation::Supply).TotalBranches > 1) {


Yeah...probably not. :)

lymereJ · 2024-07-03T20:20:19Z

@Myoldmopar - I think that I've address all your comments, please let me know if I missed something, thanks! I ran tests locally and they all passed, hopefully it'll be the same here.

Myoldmopar · 2024-07-05T14:34:02Z

@lymereJ there were still a few doc issues I had to clean up. While I was in there I added a small totally unrelated commit to quiet up a few advanced cmake vars, but that won't affect anything. I will plan on merging this shortly once the doc build finishes. Thanks.

Myoldmopar · 2024-07-05T14:52:33Z

Docs are happy now, merging.

jmarrec

Again super late to the party (sorry about that), but I'm bother by the Min Cond Flow field defaulting in the C++ code and IDD having neither default nor required field.

not a big deal, I'm just saying.

jmarrec · 2024-10-02T07:45:36Z

src/EnergyPlus/ChillerElectricEIR.hh

+        int ChillerCondLoopFlowFLoopPLRIndex = 0; // Condenser loop flow rate fraction function of loop PLR
+        int CondDT = 0;                           // Temperature difference across condenser
+        int CondDTScheduleNum = 0;                // Temperature difference across condenser schedule index
+        Real64 MinCondFlowRatio = 0.2;            // Minimum condenser flow fraction


This defaults to 0.2

In the good old days when one could edit the IDD and change the default this sort thing made sense to me. Now that the IDD is hard coded in the JSON stuff what is the difference if it is hard coded in C++ or JSON? Just saying

RTFM?

It's documentation and clarity to declare it in the IDD ('cause who reads the documentation for that?). If a blank numeric doesn't default to zero, it should have a default declared in the IDD. IDF Editor, transition, and possibly other tools may fill in that default value.

Addressed in #10779.

Okay, IDD as documentation makes good sense. But I am curious if it is okay to hardcode the default as initialization in C++ variable declaration or if the preferred practice is to handle the default value coming from input processor.

Totally agree with @mjwitte here.

Also, I've made that point several times over the years, but in my opinion, every field should be either \required-field or \default unless there's a very good reason (examples: no default value is appropriate, and it's a field that's only used based on some other choice field; or an optional loop inlet/outlet nodes). This is very helpful for anyone consuming the IDD (such as OpenStudio SDK, and IDF / EPJSON editors).

\mininimum and \maximum and the \type attributes should be used as much as possible on the fields too.

And \extensible should be used on the object itself everywhere it's appropriate.

The IDD is a schema (and the fact it's translated into the epJSON schema makes that indisputable), so it should be as good as possible, without having to RTFM or even worse go through the C++ code

Note: In the OpenStudio SDK:

We have an our own IDD for model, and we have a modified Energy+.idd for workspace (IDF), but when a new E+ version comes out, we take the official E+ idd as a basis to bring in changes. Everytime the IDD changes are lacking proper flags, we have to read the documentation AND go through the C++ code.

We know that the IDD is lacking proper flags because we're more stringent with them:

The primary reason is that we have C++ code generators scripts that will read the IDD and implement getters/setters differently based on whether a field is required, defaulted, or nothing.

The second reason is that we try hard to avoid people shooting themselves in the foot

We differentiate between a defaulted value and a user-set value (the getter returns either the defaulted or user-set value, but you have a bool isValueDefaulted() and a resetValue() method as well, and interfaces such as the OpenStudioApp will display that field differently (green if defaulted for eg))

More often than not (for HVAC objects especially), we turn a \default xxx field in a \required-field and hardcode the value in the object's ctor, as this simplifies the API (saves writing and maintaining a getter and a resetter)

jmarrec · 2024-10-02T07:46:39Z

idd/Energy+.idd.in

+  N19; \field Condenser Minimum Flow Fraction
+       \note This input corresponds to the minimum flow fraction to be simulated. The minimum condenser flow
+       \note corresponds to this fraction multiplied by the maximum condenser flow rate. This input is only used
+       \note when the "Condenser Flow Control" input is set to "ModulatedChillerPLR", "ModulatedLoopPLR" or
+       \note "ModulatedDeltaTemperature".


It bothers me that this field is neither \required-field nor \default 0.2

NFP and inital changes for Chiller:Electric:EIR.

fe5e19d

lymereJ added NewFeature Includes code to add a new feature to EnergyPlus IDDChange Code changes impact the IDD file (cannot be merged after IO freeze) labels May 17, 2024

Merge branch 'develop' into var_speed_cond_ctrl

6a58a69

Myoldmopar self-assigned this May 22, 2024

lymereJ added 2 commits May 31, 2024 16:03

Correct calcs, address inconsistencies, and add new EIO info.

0105b46

Merge branch 'develop' into var_speed_cond_ctrl

3496c04

lymereJ marked this pull request as draft May 31, 2024 23:04

lymereJ added 5 commits May 31, 2024 16:07

Remove unecessary format()...

eddc95d

Apply changes to ReformulatedEIR chiller and remove dedicated input f…

426036c

…or dT.

Input handling mods.

7cd4072

Add unit tests.

a8bde4c

Merge branch 'develop' into var_speed_cond_ctrl

78a8f30

EnergyArchmage reviewed Jun 12, 2024

View reviewed changes

lymereJ added 8 commits June 12, 2024 12:51

Add docs.

870c162

Merge branch 'develop' into var_speed_cond_ctrl

42a22ed

Revert small change.

ec2847c

Add control for minimum VS flow.

1ddd55b

Additional docs.

cd43308

Merge branch 'develop' into var_speed_cond_ctrl

26a11b9

Add example file.

df83a6e

Use condenser temperature instead of chilled water temperature.

c34186e

lymereJ added the OutputChange Code changes output in such a way that it cannot be merged after IO freeze label Jun 13, 2024

lymereJ commented Jun 13, 2024

View reviewed changes

lymereJ marked this pull request as ready for review June 13, 2024 20:46

lymereJ added this to the EnergyPlus 24.2 IOFreeze milestone Jun 13, 2024

Merge remote-tracking branch 'origin/develop' into var_speed_cond_ctrl

29c70af

Myoldmopar requested changes Jul 3, 2024

View reviewed changes

lymereJ added 2 commits July 3, 2024 12:58

Address review comments.

8d461f9

Merge branch 'develop' into var_speed_cond_ctrl

2d30aa9

Myoldmopar added 3 commits July 5, 2024 09:16

Merge remote-tracking branch 'origin/develop' into var_speed_cond_ctrl

f89b5d2

Fix remaining documentation errors

bb430cf

Take over this PR to add a few random cmake advanced tags

125f666

Myoldmopar approved these changes Jul 5, 2024

View reviewed changes

Myoldmopar merged commit 1033bdc into develop Jul 5, 2024
10 checks passed

Myoldmopar deleted the var_speed_cond_ctrl branch July 5, 2024 14:52

jmarrec reviewed Oct 2, 2024

View reviewed changes

jmarrec mentioned this pull request Oct 2, 2024

Update to EnergyPlus v24.2.0a NREL/OpenStudio#5242

Merged

19 tasks

lymereJ mentioned this pull request Oct 2, 2024

Add minimum and default for the Condenser Minimum Flow Fraction field #10779

Open

12 tasks

		\({CAP_{CHWL}}\) is the design chilled water loop capacity determined using inputs from the Sizing:Plant object for the loop


		The condenser plant loop water flow fraction (\({CWFR}\)) corresponding to the \({PLR_{CWHL}}\) is obtained by feeding it through a user-specified curve. A linear curve is expected: \(CWFR = C * {PLR_{CHWL}} + D\) where C and D are coefficients. A reference for these coefficients is provided in ``Optimizing Design & Control Of Chilled Water Plants, Part 5'', S. Taylor, ASHRAE Journal June 2012.

		@@ -2131,6 +2148,22 @@ \subsubsection{Inputs}\label{inputs-5-021}

		This optional field allows you to specify a user-defined end-use subcategory, e.g., ``Process''. A new meter for reporting is created for each unique subcategory (ref: \hyperref[outputmeter-and-outputmetermeterfileonly]{Output:Meter} objects). Any text may be used here to further subcategorize the end-uses in the ABUPS End Uses by Subcategory table and in the LEED Summary EAp2-4/5 Performance Rating Method Compliance table. If this field is omitted or blank, the chiller will be assigned to the ``General'' end-use subcategory.

		\paragraph{Field: Condenser Flow Control}\label{field-condenser-flow-control}


		This field is optional.~ It describes the chiller condenser flow request mode to be used in a simulation. With ``ConstantFlow'' a chiller will always request its maximum condenser flow rate. With ``ModulatedChillerPLR'' the condenser flow request corresponds to the chiller part load ratio multiplied by the chiller maximum condenser flow rate. With ``ModulatedLoopPLR'' the chiller will request a flow rate that is function of the chilled water loop's part load ratio, see the \hyperref[field-condenser-loop-flow-rate-function-of-loop-part-load-ratio-curve-name]{Condenser Loop Flow Rate Fraction Function of Loop Part Load Ratio Curve Name} input. With ``ModulatedDeltaTemperature'' the chiller will request the flow rate required to meet a condenser loop delta temperature, see the \hyperref[field-temperature-difference-across-condenser-schedule-name]{Temperature Difference Across Condenser Schedule Name} input. Use ``ConstantFlow'' when modeling a constant flow condenser plant loop, choose one of the other inputs when modeling a variable flow condenser plant loop. The default is ``ConstantFlow''.

		\paragraph{Field: Condenser Loop Flow Rate Fraction Function of Loop Part Load Ratio Curve Name}\label{field-condenser-loop-flow-rate-function-of-loop-part-load-ratio-curve-name}


		This field describes the condenser loop flow rate fraction as a function of the chiller water loop part load ratio. A linear curve is expected: CWFR = C * PLR + D where CWFR is the condenser water flow fraction (actual/design), PLR is the chilled water plant loop part load ratio (actual/design), and C and D are coefficients. A reference for these coefficients is provided in ``Optimizing Design & Control Of Chilled Water Plants, Part 5'', S. Taylor, ASHRAE Journal June 2012. This input is only used when the ``ModulatedLoopPLR'' condenser flow control option is used.

		\paragraph{Field: Temperature Difference Across Condenser Schedule Name}\label{field-temperature-difference-across-condenser-schedule-name}

Variable flow condenser plant control #10511

Variable flow condenser plant control #10511

Conversation

lymereJ commented May 17, 2024 • edited Loading

Pull request overview

Pull Request Author

Reviewer

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lymereJ commented Jun 13, 2024

lymereJ left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lymereJ commented Jun 13, 2024

Myoldmopar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lymereJ commented Jul 3, 2024

Myoldmopar commented Jul 5, 2024

Myoldmopar commented Jul 5, 2024

jmarrec left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lymereJ commented May 17, 2024 •

edited

Loading

lymereJ left a comment •

edited

Loading