Fix VRFFluidCtrl cooling cycling issue by moving cycling ratio calc in compressor spd calc #10353

yujiex · 2024-01-04T01:28:30Z

Pull request overview

Fixes VRF cooling issue: same cooling power with different min-speed curve at low cooling load #10105
The range of the outdoor evaporating temperature is updated to match the valid range of the indoor unit evaporating temperature.

The following shows the relevant code flow chart. We observed a problem of non-matching minimum-speed compressor capacity at two places

For the same timestep, in the cycling ratio calculation, the demand is larger than minimum speed capacity, and the compressor is considered not cycling. However in the compressor speed calculation later on, the demand is smaller than the minimum speed capacity, and the compressor is considered cycling

The difference in the minimum-speed-capacity is caused by the difference in the evaporating temperature.

To fix this, we propose to move the cycling calculation inside the compressor speed calculation as is shown in the following diagram.

Effect of the fix

The following shows the output before the fix

The following shows the output after the fix.

After the fix, runtime fractions are different now, where the lower-capacity one runs longer. For the same cooling rate, the heat pump cooling electricity rate and COP are more similar. The evaporating temperature output also reflected the following Te adjustment when the compressor is at the lowest speed (minimum loading index)

Regression diffs

The regression diffs happen in the following files with VRF FluidTCtrl models

US+SF+CZ4A+hp+crawlspace+IECC_2006_VRF
VariableRefrigerantFlow_FluidTCtrl_5Zone
VariableRefrigerantFlow_FluidTCtrl_HR_5Zone
VariableRefrigerantFlow_FluidTCtrl_wSuppHeater_5Zone

The four files all have table diffs in electricity rate. The following is in the table diff in VariableRefrigerantFlow_FluidTCtrl_5Zone. These are anticipated as the cycling ratio calculation is modified and the cooling electricity rate should change. As a result, the total electricity rate should also change.

Meter difference happens in the following two files. The differences are in Cooling:Electricity, Electricity:HVAC, and Electricity:Facility. The diffs are expected as cycling ratio can affect the cooling electricity rate, which leads to changes in these "Electricity:*" variables.

VariableRefrigerantFlow_FluidTCtrl_5Zone
VariableRefrigerantFlow_FluidTCtrl_HR_5Zone

The following is from the output of the "VariableRefrigerantFlow_FluidTCtrl_5Zone.idf".

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.

Reviewer

This will not be exhaustively relevant to every PR.

…nto vrfFluidCtrlFixCoolingCycling

…lingCycling

yujiex · 2024-03-06T19:31:33Z

src/EnergyPlus/HVACVariableRefrigerantFlow.cc

+    } else {
+        PLF = 1.0;
+    }
+    if (coolingCoil.TotalCoolingEnergyRate > 0.0) {


this keeps the coil RTF up-to-date with the condenser side

yujiex · 2024-03-06T19:32:35Z

src/EnergyPlus/HVACVariableRefrigerantFlow.cc

@@ -14429,12 +14440,19 @@ void VRFCondenserEquipment::VRFOU_CalcCompC(EnergyPlusData &state,
                    goto Label13;
                }

-                if (CapDiff > (Tolerance * Cap_Eva0)) NumIteCcap = 999;
+                if (CapDiff > (Tolerance * Cap_Eva0)) {


cycling ratio calculation is moved to here

This logic does not seem right to me. At line 14439 this same conditional is used. It says if the capacity difference is greater than some tolerance keep iterating. So when we get to line 14447, it's either due to max iterations or the capacity difference is less than tolerance. I guess if capacity difference is less than tolerance then we converged on the capacity that requires the compressor to run the entire time step. But if (NumIteCcap >= 30) then what does that mean? I'm not sure it means the compressor is cycling. I think it might mean the compressor is cycling if Cap_Eva1 - Cap_Eva0 is positive but you don't know that since CapDiff = std::abs(Cap_Eva1 - Cap_Eva0); I would think that should be accounted for here. I'm not sure though since this is a very detailed model.

if (CapDiff > (Tolerance * Cap_Eva0) && (Cap_Eva1 - Cap_Eva0) >= 0.0)

Indeed. If Cap_Eva1 - Cap_Eva0 < 0 then it should not cycle.

…lingCycling

mjwitte · 2024-03-07T18:38:38Z

@yujiex For the defect file attached to #10105 these code changes don't alter the relative behavior between the two defect files (i.e. the stated speed at load range 1 has no impact on results other than the reported speed value, see #10105 (comment)). The results in both the 900 and 1320 file both change the same way.

But this PR does expose the fact that the initial check of load vs min-capacity has a significantly different value for CompEvaporatingCAPSpdMin than the equivalent check later on in the speed-selection pass. Looking at the code in develop, here's the first block in VRFCondenserEquipment::CalcVRFCondenser_FluidTCtrl:

EnergyPlus/src/EnergyPlus/HVACVariableRefrigerantFlow.cc

Lines 11531 to 11543 in 769463d

    
           // Condenser (OU side) operation ranges 
        
           CapMaxPc = min(Psuction + this->CompMaxDeltaP, RefMaxPc); 
        
           CapMaxTc = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(CapMaxPc, RefPHigh), RefPLow), RefrigerantIndex, RoutineName); 
        
           CapMinTc = OutdoorDryBulb + this->SC; 
        
           CapMinPc = GetSatPressureRefrig(state, this->RefrigerantName, CapMinTc, RefrigerantIndex, RoutineName); 
        
           // Evaporator (IU side) operation ranges 
        
           CapMinPe = max(CapMinPc - this->CompMaxDeltaP, RefMinPe); 
        
           CapMinTe = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(CapMinPe, RefPHigh), RefPLow), RefrigerantIndex, RoutineName); 
        
           // Evaporative capacity ranges 
        
           CompEvaporatingCAPSpdMin = this->CoffEvapCap * this->RatedEvapCapacity * CurveValue(state, this->OUCoolingCAPFT(1), CapMinTc, CapMinTe); 
        
           CompEvaporatingPWRSpdMin = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(1), CapMinTc, CapMinTe);

And here's the second block:

EnergyPlus/src/EnergyPlus/HVACVariableRefrigerantFlow.cc

Lines 11838 to 11842 in 769463d

    
           // Evaporative capacity ranges_Min 
        
           CapMinPe = min(Pdischarge - this->CompMaxDeltaP, RefMinPe); 
        
           CapMinTe = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(CapMinPe, RefPHigh), RefPLow), RefrigerantIndex, RoutineName); 
        
           CompEvaporatingCAPSpdMin = this->CoffEvapCap * this->RatedEvapCapacity * CurveValue(state, this->OUCoolingCAPFT(1), Tdischarge, CapMinTe); 
        
           CompEvaporatingPWRSpdMin = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(1), Tdischarge, CapMinTe);

So my question would be why the first one is using CapMinTc = OutdoorDryBulb + this->SC to evaluate the capacity curve, while the second block is using Tdischarge where

        Tdischarge = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(Pdischarge, RefPHigh), RefPLow), RefrigerantIndex, RoutineName);

yujiex · 2024-03-07T19:18:48Z

@yujiex For the defect file attached to #10105 these code changes don't alter the relative behavior between the two defect files (i.e. the stated speed at load range 1 has no impact on results other than the reported speed value, see #10105 (comment)). The results in both the 900 and 1320 file both change the same way.

But this PR does expose the fact that the initial check of load vs min-capacity has a significantly different value for CompEvaporatingCAPSpdMin than the equivalent check later on in the speed-selection pass. Looking at the code in develop, here's the first block in VRFCondenserEquipment::CalcVRFCondenser_FluidTCtrl:

EnergyPlus/src/EnergyPlus/HVACVariableRefrigerantFlow.cc

Lines 11531 to 11543 in 769463d

// Condenser (OU side) operation ranges

CapMaxPc = min(Psuction + this->CompMaxDeltaP, RefMaxPc);

CapMaxTc = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(CapMaxPc, RefPHigh), RefPLow), RefrigerantIndex, RoutineName);

CapMinTc = OutdoorDryBulb + this->SC;

CapMinPc = GetSatPressureRefrig(state, this->RefrigerantName, CapMinTc, RefrigerantIndex, RoutineName);

// Evaporator (IU side) operation ranges

CapMinPe = max(CapMinPc - this->CompMaxDeltaP, RefMinPe);

CapMinTe = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(CapMinPe, RefPHigh), RefPLow), RefrigerantIndex, RoutineName);

// Evaporative capacity ranges

CompEvaporatingCAPSpdMin = this->CoffEvapCap * this->RatedEvapCapacity * CurveValue(state, this->OUCoolingCAPFT(1), CapMinTc, CapMinTe);

CompEvaporatingPWRSpdMin = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(1), CapMinTc, CapMinTe);

And here's the second block:

EnergyPlus/src/EnergyPlus/HVACVariableRefrigerantFlow.cc

Lines 11838 to 11842 in 769463d

// Evaporative capacity ranges_Min

CapMinPe = min(Pdischarge - this->CompMaxDeltaP, RefMinPe);

CapMinTe = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(CapMinPe, RefPHigh), RefPLow), RefrigerantIndex, RoutineName);

CompEvaporatingCAPSpdMin = this->CoffEvapCap * this->RatedEvapCapacity * CurveValue(state, this->OUCoolingCAPFT(1), Tdischarge, CapMinTe);

CompEvaporatingPWRSpdMin = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(1), Tdischarge, CapMinTe);

So my question would be why the first one is using CapMinTc = OutdoorDryBulb + this->SC to evaluate the capacity curve, while the second block is using Tdischarge where
        Tdischarge = GetSatTemperatureRefrig(state, this->RefrigerantName, max(min(Pdischarge, RefPHigh), RefPLow), RefrigerantIndex, RoutineName);

My understanding is the CompEvaporatingCAPSpdMin check in the first block before entering the compressor speed calculation might be a rougher guess and the second place considers the piping loss and is more accurate.

mjwitte

A few more comments. I would like @rraustad to review also.

mjwitte · 2024-03-08T17:02:42Z

src/EnergyPlus/HVACVariableRefrigerantFlow.cc

@@ -283,6 +283,27 @@ void SimulateVRF(EnergyPlusData &state,
        if (state.dataHVACVarRefFlow->VRF(VRFCondenser).CondenserType == DataHeatBalance::RefrigCondenserType::Water)
            UpdateVRFCondenser(state, VRFCondenser);
    }
+    // yujie: update coil and IU evaporating temperature, also keep coil RTF updated with the condenser side cycling ratio, for the FluidTCtrl model


Current practice is to leave names out of comments.

I'll remove the name

mjwitte · 2024-03-08T17:12:18Z

src/EnergyPlus/HVACVariableRefrigerantFlow.cc


-                Ncomp = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(CounterCompSpdTemp), T_discharge, T_suction);
+                Ncomp = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(CounterCompSpdTemp), T_discharge, T_suction) * CyclingRatio;
+                OUCondHeatRelease = Cap_Eva1 * CyclingRatio;


I don't think this is correct. Earlier OUCondHeatRelease = TU_load + Pipe_Q + Ncomp;
Possibly OUCondHeatRelease *= CyclingRatio; would be correct here?

or would it be Ncomp + Cap_Eva1 * CyclingRatio? similar to the load > maximum capacity case

if (CounterCompSpdTemp > NumOfCompSpdInput) { // Required load is beyond the maximum system capacity CompEvaporatingCAPSpd(NumOfCompSpdInput) = this->CoffEvapCap * this->RatedEvapCapacity * CurveValue(state, this->OUCoolingCAPFT(NumOfCompSpdInput), T_discharge, T_suction); OUCondHeatRelease = Ncomp + CompEvaporatingCAPSpd(NumOfCompSpdInput); CompSpdActual = this->CompressorSpeed(NumOfCompSpdInput); Ncomp = CompEvaporatingPWRSpd(NumOfCompSpdInput); }

Ncomp is updated inside VRFOU_CalcCompC, so maybe that part needs to use the updated Ncomp?, When it is cycling, CyclingRatio = (TU_load + Pipe_Q) * C_cap_operation / Cap_Eva1, then Ncomp + Cap_Eva1 * CyclingRatio would evaluates to Ncomp + (TU_load + Pipe_Q) * C_cap_operation, with the updated Ncomp and the TU_load + Pipe_Q considering the difference between the rated and real condition (C_cap_operation)

That sounds ok. This function is very hard to follow, so I'll trust you on that.

It would be a nice test to plot some of the available report variables through a transition from CyclingRatio = 1 at some time step to CyclingRatio < 1 at future time steps to see if these report variables have a smooth transition from compressor on to compressor cycling. Whichever reports capture the equations being questioned here. Not sure why a component model is not reporting refrigerant pressures which could help in diagnostics. We should add refrigerant temperature/pressure reporting at some point.

good idea. I will produce some plot showing how CyclingRatio transition from 1 to < 1 and the other way

Also add VRF Heat Pump Outdoor Unit Evaporator Heat Extract Rate so we can see what is happening at the evaporator.

@dareumnam and @rraustad. I created the following plots. There is not an output variable for refrigerant flow. I will add some custom outputs later. The Outdoor Unit Evaporator Heat Extract Rate is 0 during cooling mode, in both periods, 04/06 and 04/09.

The following are a few plots for the 04/09 period. The fact that heat pump electricity is higher when cycling ratio < 1 than when cycling ratio = 1, seems to originate from the compressor power, which also has this behavior. I will dig deeper into this.

compare_outputs_cyclingRatio_non1to2_update.xlsx

I looked at the following two points, at 4/6 12:20 and 4/6/ 14:20. The former has heat pump cycling ratio = 0.949, the latter has cycling ratio of 1.0. The former has higher compressor power (which leads to higher heat pump electricity rate) than the latter.

This is because its evaporating temperature is lower. The condensing temperature is pretty similar, lower evaporating temperature will lead to higher curve value (see the following compressor curve at this speed).

As the compressor electricity rate is computed as the following, the compressor power (before multiplying cycling ratio is higher) at the 12:20 due to lower evaporating temperature.

Ncomp = this->RatedCompPower * CurveValue(state, this->OUCoolingPWRFT(CounterCompSpdTemp), T_discharge, T_suction);

The evaporating temperature is lowered during cycling as there was a low-load modification mechanism in the fluid control VRF, where they enlarge the compressor evaporating capacity by changing the evaporating temperature (see the red shaded part), so that the equipment can cycle less.

@rraustad @dareumnam

Are the refrigerant mass flow rates the same at both points? (4/6 12:20 and 4/6/ 14:20)

Hi @dareumnam, there is not a refrigerant flow rate output variable. I used some debug prints to output this variable (m_ref_IU_evap_i and m_ref_IU_evap in cooling mode). The refrigerant flow at 12:20 is 0.01058698505294939, and the refrigerant flow at 14:20 is 0.012904189061317716.

mjwitte · 2024-03-08T17:18:48Z

testfiles/speed_1320.idf

@@ -0,0 +1,7429 @@
+!- ---------------------------------------------------------------------------------------------------------
+!- The Residential Prototype Building Models were developed by Pacific Northwest National Laboratory (PNNL),


The defect files got added by mistake.

let me remove it

This reverts commit 96f9e2c.

…lingCycling

…EL/EnergyPlus into vrfFluidCtrlFixCoolingCycling

yujiex · 2024-06-25T17:40:41Z

This effort got a little off the rails with discussion. The original issue was a difference in power/COP with a change in the min speed curve limit. This is very hard to understand for a model that is changing coil air flow to meet a load, and the refrigerant side property (Te), which could then impact the condensing temp (Tc). The cycling issue with PLF should not change the energy use magnitude much because it's just a startup loss so comparing cycling to not cycling is just a small difference (more energy if cycling), if everything else is the same. But with this model, everything else is not the same. We should back up to the original issue and compare a develop to this branch result. Is energy use now as expected? Annual energy difference? Are the code changes reasonable?, etc.

Regarding the original issue. The speed_900.idf has 8 speed levels, the lowest speed level curve is curve set 1. The speed_1920.idf has 7 speed levels, the lowest speed level curve is curve set 2. speed_1920.idf is derived from speed_900.idf by removing the lowest speed level curve set (there are two curves for each speed level). The following are the "Evaporative Capacity Multiplier Function of Temperature Curve Name" and "Compressor Power Multiplier Function of Temperature Curve Name" of Curve 1 and 2 at 35F are most relevant.

The following is the develop branch output. We can see that both of them have cycling ratio=1. However, with different lowest-speed curves, they still deliver the same total cooling rate. This is unreasonable.

The following is the feature branch output. We can see in both cases the VRF system is cycling. Since curve set 1 can supply lower cooling capacity for the same evaporating, condensing temperature combination, it should cycle less, which is indeed the case here. Compressor power for the speed_900 output is slightly larger than the speed_1920 one as it runs for longer period and that the power curve is higher.

Annual energy difference is shown in the following table

The following attaches the input idfs and output tables
ouput_dev.zip
output_feature.zip
input.zip

@rraustad

…lingCycling

yujiex · 2024-07-23T16:36:48Z

@Myoldmopar and @dareumnam would you mind taking another look at this PR? Thanks.

…lingCycling

dareumnam · 2024-07-31T06:22:45Z

So, in the original issue, the min-compressor-speed capacity was different at two points in the code flow. To fix this, you moved the cycling ratio calculation inside the compressor speed calculation. After the fix, the output from this branch shows a different cycling ratio, which seems reasonable. Could you please explain a bit more about whether the energy use or VRF cooling electricity rate are as expected? I would like to be convinced that the Heat Pump Electricity Rate shown above is correct.
@rraustad, do you have any further comments or suggestions?

yujiex · 2024-07-31T23:08:22Z

So, in the original issue, the min-compressor-speed capacity was different at two points in the code flow. To fix this, you moved the cycling ratio calculation inside the compressor speed calculation. After the fix, the output from this branch shows a different cycling ratio, which seems reasonable. Could you please explain a bit more about whether the energy use or VRF cooling electricity rate are as expected? I would like to be convinced that the Heat Pump Electricity Rate shown above is correct. @rraustad, do you have any further comments or suggestions?

@dareumnam Looking at the tables in this comment. Compressor power become much more similar after the fix. This is anticipated, as according to the power multiplier curve plots in the same comment, the curve 1 value is around 0.07 and the curve 2 value is around 0.1 (a 0.7 to 1 relationship). The curve value need to multiply the rated compressor power and cycling ratio to get the compressor power. The cycling ratio of the two example files are about 0.55 to 0.81 (see first row of the second table below the curve plots in that same comment), which is a 1 to 0.68 relationship. Since the power curve values are 0.7 to 1 (between the two examples) and the cycling ratios are 1 to 0.68, the final compressor power should be pretty similar.

This leads to very similar heat pump cooling electricity rate after the fix. This is reasonable as the cooling electricity rate is the sum of compressor power and fan power. Fan power here is the same. Compressor power is very similar as is explained above, heat pump cooling electricity rate should also be similar.

dareumnam · 2024-08-28T17:03:42Z

Thanks for the detailed explanation which makes sense to me. I built this branch locally, and everything looks clean. The diffs are expected and well-explained. I appreciate your hard work on the VRF models, @yujiex. I believe this is ready to be merged. @Myoldmopar

yujiex · 2024-08-28T17:05:35Z

Thanks @dareumnam

This reverts commit 1c35238.

github-actions · 2024-09-04T21:13:18Z

⚠️ Regressions detected on macos-14 for commit `e11a470`

Regression Summary

ESO Big Diffs: 4
Table Big Diffs: 4
Table String Diffs: 1
MTR Big Diffs: 2
EIO: 1

github-actions · 2024-09-04T21:22:21Z

⚠️ Regressions detected on macos-14 for commit `f34d890`

Regression Summary

ESO Big Diffs: 4
Table Big Diffs: 4
Table String Diffs: 1
MTR Big Diffs: 2
EIO: 1

…lingCycling

github-actions · 2024-09-05T17:23:22Z

⚠️ Regressions detected on macos-14 for commit `457b324`

Regression Summary

ESO Big Diffs: 4
Table Big Diffs: 4
Table String Diffs: 1
MTR Big Diffs: 2
EIO: 1

Myoldmopar · 2024-09-10T18:11:19Z

src/EnergyPlus/Material.cc

@@ -211,7 +211,7 @@ void GetMaterialData(EnergyPlusData &state, bool &ErrorsFound) // set to true if
        state.dataMaterial->TotMaterials += 1 + TotFfactorConstructs + TotCfactorConstructs;
    }

-    // yujie: This looks kind of silly, but we need it to keep the Materials array in IDF order.
+    // This looks kind of silly, but we need it to keep the Materials array in IDF order.


This caused a conflict. I'll fix it.

Actually maybe it wasn't this...?

…lingCycling

Myoldmopar · 2024-09-10T18:18:19Z

Alright, resolved the conflict and built/tested. Everything is all happy. This will merge assuming CI stays clean.

github-actions · 2024-09-10T19:03:11Z

⚠️ Regressions detected on macos-14 for commit `6f3ea79`

Regression Summary

ESO Big Diffs: 4
Table Big Diffs: 4
Table String Diffs: 1
MTR Big Diffs: 2
EIO: 1

Myoldmopar · 2024-09-11T14:31:27Z

Alright, merging here. Thanks @yujiex , and @dareumnam.

yujiex · 2024-09-11T16:22:27Z

Thanks @Myoldmopar

move cycling ratio calculation inside compressor spd calc

ba0d9f4

yujiex added the Defect Includes code to repair a defect in EnergyPlus label Jan 4, 2024

yujiex self-assigned this Jan 4, 2024

yujiex marked this pull request as draft January 4, 2024 01:28

Yujie Xu and others added 8 commits January 22, 2024 16:31

move cycling into compressor speed calculation

5d582f0

change outdoor unit evap temperature threshold

fa3e488

overwrite indoor Te withoutdoor adjusted Te

452e53b

Merge remote-tracking branch 'origin/vrfFluidCtrlFixCoolingCycling' i…

7bb2e4b

…nto vrfFluidCtrlFixCoolingCycling

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

d23a27a

…lingCycling

overwrite IU Te, coil RTF update

25ffe67

Only overwrite Coil RTF when in cooling mode

6539294

ncomp calc need to multiply cycling ratio

3601caa

yujiex commented Mar 6, 2024

View reviewed changes

yujiex requested review from Myoldmopar, mjwitte and rraustad March 6, 2024 19:33

yujiex added this to the EnergyPlus 24.1 milestone Mar 6, 2024

Yujie Xu added 2 commits March 6, 2024 11:37

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

00d8f25

…lingCycling

update Te and RTF only happens in the FluidTCtrl model

68fb801

Yujie Xu added 3 commits March 7, 2024 13:23

test idf for different min speed level, will remove later

96f9e2c

account for cycling ratio in condenser heat release

ecb2ae0

test case for VRFOU_CalcCompC low load cycling

7acd424

mjwitte reviewed Mar 8, 2024

View reviewed changes

Yujie Xu added 3 commits March 8, 2024 09:29

OUCondHeatRelease = Ncomp + Cap_Eva1 * CyclingRatio;

84141c6

Revert "test idf for different min speed level, will remove later"

a8cef58

This reverts commit 96f9e2c.

remove name tag in the comments

7a38358

yujiex marked this pull request as ready for review March 8, 2024 18:01

Yujie Xu added 3 commits June 24, 2024 17:54

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

1b66089

…lingCycling

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

3e0fb35

…lingCycling

Merge branch 'vrfFluidCtrlFixCoolingCycling' of https://github.com/NR…

8ba4828

…EL/EnergyPlus into vrfFluidCtrlFixCoolingCycling

Yujie Xu added 3 commits June 27, 2024 10:58

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

d3fb4a8

…lingCycling

remove temporary testfiles

820765a

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

6253ece

…lingCycling

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

f4c425b

…lingCycling

mjwitte self-assigned this Jul 31, 2024

Yujie Xu added 2 commits September 4, 2024 13:23

change default value of MaxHeat(Cool)ingCapacity to MaxCap

1c35238

Revert "change default value of MaxHeat(Cool)ingCapacity to MaxCap"

acb84a0

This reverts commit 1c35238.

Yujie Xu added 2 commits September 5, 2024 09:26

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

7f84730

…lingCycling

fix unit test

08eb126

Myoldmopar reviewed Sep 10, 2024

View reviewed changes

Myoldmopar added 2 commits September 10, 2024 13:17

Merge develop; resolve conflicts

eb4bc0e

Merge remote-tracking branch 'origin/develop' into vrfFluidCtrlFixCoo…

5907d73

…lingCycling

Myoldmopar merged commit e2692dd into develop Sep 11, 2024
10 checks passed

Myoldmopar deleted the vrfFluidCtrlFixCoolingCycling branch September 11, 2024 14:31

		@@ -0,0 +1,7429 @@
		!- ---------------------------------------------------------------------------------------------------------
		!- The Residential Prototype Building Models were developed by Pacific Northwest National Laboratory (PNNL),

Fix VRFFluidCtrl cooling cycling issue by moving cycling ratio calc in compressor spd calc #10353

Fix VRFFluidCtrl cooling cycling issue by moving cycling ratio calc in compressor spd calc #10353

Conversation

yujiex commented Jan 4, 2024 • edited Loading

Pull request overview

Effect of the fix

Regression diffs

Pull Request Author

Reviewer

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

mjwitte commented Mar 7, 2024

yujiex commented Mar 7, 2024

mjwitte 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

yujiex Mar 8, 2024 • 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

yujiex commented Jun 25, 2024

yujiex commented Jul 23, 2024 • edited Loading

dareumnam commented Jul 31, 2024

yujiex commented Jul 31, 2024

dareumnam commented Aug 28, 2024

yujiex commented Aug 28, 2024

github-actions bot commented Sep 4, 2024

⚠️ Regressions detected on macos-14 for commit e11a470

github-actions bot commented Sep 4, 2024

⚠️ Regressions detected on macos-14 for commit f34d890

github-actions bot commented Sep 5, 2024

⚠️ Regressions detected on macos-14 for commit 457b324

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Myoldmopar commented Sep 10, 2024

github-actions bot commented Sep 10, 2024

⚠️ Regressions detected on macos-14 for commit 6f3ea79

Myoldmopar commented Sep 11, 2024

yujiex commented Sep 11, 2024

yujiex commented Jan 4, 2024 •

edited

Loading

yujiex Mar 8, 2024 •

edited

Loading

yujiex commented Jul 23, 2024 •

edited

Loading

⚠️ Regressions detected on macos-14 for commit `e11a470`

⚠️ Regressions detected on macos-14 for commit `f34d890`

⚠️ Regressions detected on macos-14 for commit `457b324`

⚠️ Regressions detected on macos-14 for commit `6f3ea79`