Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better humidity control for chilled water coils and for AirloopHVAC:UnitarySystem #7215

Merged
merged 18 commits into from
Mar 20, 2019

Conversation

mjwitte
Copy link
Contributor

@mjwitte mjwitte commented Mar 8, 2019

Pull request overview

  1. Addresses UnitarySystem set point based control of humidity not working correctly #6892 to fix humidity control in AirloopHVAC:UnitarySystem. This is also alternate solution to Improved chilled water coil humidity control #7001, using AirloopHVAC:UnitarySystem to control the chilled water coil instead of Controller:WaterCoil. This required a few tweaks to avoid uninitialized variables and get things to control well, but this pegs the leaving dry-bulb setpoint or the leaving humidity ratio setpoint, and reliably switches between the two. (See EnergyPlusDevSupport\DefectFiles for an idf like this). At present, there are still some warnings of "Iteration limit exceeded calculating latent part-load ratio for unit", so may need some more tweaks, but that may just be how it is.
  • Chilled water coil
  • DX single speed

Defect Files

7001 defect file no longer crashes in debug build and maintains the Node 27 humidity ratio within 9.8e-05 of the humidity ratio setpoint of 0.011388. The jagged profile comes from using a humidity ratio control tolerance of 1.0e-04 (arbitrarily chosen to be tight, but not so tight that there are max iteration problems). Maybe that should be tighter.

image

For 6892 there are three defect files, 6892-in_Copy-HumCtrl, DOAS_CWCoil-UseUnitarySystem, DOAS_DXCoil-UseUnitarySystem:
DOAS_CWCoil-UseUnitarySystem - crashes with develop debug build, runs fine and controls almost exactly to setpoint with develop release build. This branch, runs fine and controls well with both release and debug builds.

DOAS_DXCoil-UseUnitarySystem - crashes with develop debug build, runs fine and does not control humidity with develop release build. T
his branch, runs fine and controls well with both release and debug builds.
image

Other Diffs Summary

HospitalBaseline, HospitalBaselineReheatReportEMS, HospitalLowEnergy, RefBldgHospitalNew2004_Chicago - small diffs in results, eio diffs are all in the warmup convergence details, and err diffs are either fewer or rearranged max iteration messages.

5ZoneCoolingPanel*, 5Zone*Baseboard*, 5ZoneWaterCooled*, HeatPumpWaterHeater* - eio diffs are all in the warmup convergence details, no err diffs, big diffs in results.

Reviewed 5ZoneCoolingPanelBaseboard results - Space2-1 humidity control is similar to before, still not pegged at 50%, main cooling coil load is 0.4% less, and main heating coil load is 0.8% less. Expect similar for the other cooling panel files.

Reviewed 5ZoneWaterCooled_Baseboard results - again humidity control is similar, coil loads 0.1%-0.4% less.

Reviewed HeatPumpWaterHeater results - similar humidity control, 0.04% higher main cooling coil load, 0.5% lower main heating coil load

Work Checklist

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)
  • At least one of the following appropriate labels must be added to this PR to be consumed into the changelog:
    • Defect: This pull request repairs a github defect issue. The github issue should be referenced in the PR description
    • Refactoring: This pull request includes code changes that don't change the functionality of the program, just perform refactoring
    • NewFeature: This pull request includes code to add a new feature to EnergyPlus
    • Performance: This pull request includes code changes that are directed at improving the runtime performance of EnergyPlus
    • DoNoPublish: This pull request includes changes that shouldn't be included in the changelog

Review Checklist

This will not be exhaustively relevant to every PR.

  • Functional code review (it has to work!)
  • If defect, results of running current develop vs this branch should exhibit the fix
  • CI status: all green or justified
  • Performance: CI Linux results include performance check
  • Unit Test(s)
  • C++ checks:
    • Argument types
    • If any virtual classes, ensure virtual destructor included, other things
  • IDD changes:
    • Verify naming conventions and styles, memos and notes and defaults
    • Open windows IDF Editor with modified IDD to check for errors
    • If transition, add to input rules file for interfaces
    • If transition, add transition source
    • If transition, update idfs
  • If new idf included, locally check the err file and other outputs
  • Required documentation updates?
  • ExpandObjects changes?
  • If output changes, including tabular output structure, add to output rules file for interfaces

@mjwitte mjwitte added this to the EnergyPlus 9.1.0 milestone Mar 8, 2019
@mjwitte mjwitte added the Defect Includes code to repair a defect in EnergyPlus label Mar 8, 2019
}
if (CoolCapCtrl == VAV) {
DesExitTemp = FinalSysSizing(SysNum).CoolSupTemp;
DesFlow = FinalSysSizing(SysNum).MassFlowAtCoolPeak / StdRhoAir;
} else if (CoolCapCtrl == OnOff) {
DesExitTemp = FinalSysSizing(SysNum).CoolSupTemp;
DesFlow = DataAirFlowUsedForSizing;
} else if (TimeStepAtPeak == 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TimeStepAtPeak can't be 0 if VAV or OnOff fan control is used? If so then this line won't get hit. This IF test should be first in list?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see. You put this IF test before those that use TimeStepAtPeak.

}
if (CoolCapCtrl == VAV) {
DesExitTemp = FinalSysSizing(SysNum).CoolSupTemp;
DesFlow = FinalSysSizing(SysNum).MassFlowAtCoolPeak / StdRhoAir;
} else if (CoolCapCtrl == OnOff) {
DesExitTemp = FinalSysSizing(SysNum).CoolSupTemp;
DesFlow = DataAirFlowUsedForSizing;
} else if (TimeStepAtPeak == 0) {
ShowFatalError("GetCoilDesFlow: AirLoopHVAC=" + SysSizInput(SysNum).AirPriLoopName +
" Central Cooling Capacity Control Method requires zone thermostats to calculate timestep loads.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can still have a no design load condition (and therefore a 0 for time step at peak) even though a Tstat is used. Remember when zone return temp at heating peak was 0 and TU coils weren't sizing correctly? It's the combination of Tstat temp (i.e., zone temp during sizing) and supply air temp that yields a non-zero zone mass flow rate. Isn't there another way to know if a Tstat is used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, even with a tstat, there could be zero peak. So, should these methods throw a warning if there's no peak day/time and revert to one of the other methods?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change the warning text to say exactly what has happened (inside the else if's below) and revert to sizing with CoolSupTemp and MassFlowAtCoolPeak?

@@ -1465,6 +1434,10 @@ namespace HVACControllers {
(0.001 / (2100.0 * max(ControllerProps(ControlNum).MaxVolFlowActuated, SmallWaterVolFlow))) * (HVACEnergyToler / 10.0);
// do not let the controller tolerance exceed 1/10 of the loop temperature tolerance.
ControllerProps(ControlNum).Offset = min(0.1 * HVACTemperatureToler, ControllerProps(ControlNum).Offset);
if (ControllerProps(ControlNum).ControlVar == HVACControllers::iTemperatureAndHumidityRatio) {
// for temperature and humidity control, need tighter tolerance if humidity control kicks in
ControllerProps(ControlNum).Offset = ControllerProps(ControlNum).Offset*0.1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to be able to trigger a tighter tolerance only when HumRatCtrlOverride = true.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that first but it didn't work. There's some initial setup step that I couldn't find that includes the offset.

@@ -2960,6 +2963,31 @@ namespace SimAirServingZones {
// not converge
ControllerConvergedFlag = PrimaryAirSystem(AirLoopNum).ControlConverged(AirLoopControlNum);
IsUpToDateFlag = true;
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will require multiple more iterations of the air loop components. Wouldn't it be better to use the lesser of T and TdpFw as the temperature set point up at line 1283 - 1289 of HVACControllers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try that on a separate branch, but I think it will over-dehumidify.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or use T and TdpFw as a trigger to choose which set point to use, temperature or humidity ratio.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, don't need to try that. The humidity ratio setpoint is 0.011388 which is roughly Tdp=15.9C. There are many hours where the coil can meet the humidity ratio setpoint with a leaving temperature of 16-17C, and there are many hours where the leaving air is saturated. That's why this needs to switch gears and can't just use Tdp.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, how can Tdp come out lower than supply air T? If a dry coil then yes, but a wet coil? Not your problem at this point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'cause the water temp is well below Tdp, and some of the air bypasses the coil, so the resulting mix can be drier than saturation.

@mjwitte
Copy link
Contributor Author

mjwitte commented Mar 12, 2019

So, the diffs are not good. The TemperatureAndHumidityRatio files with autosized controller tolerance now have a smaller tolerance by 10x which leads to max iteration problems, and the ones with a fixed controller tolerance of, e.g. 0.002 are too loose on the humidity control. Need to figure out how to have a variable tolerance - where that lives in the controller rootfinder stuff.

@rraustad
Copy link
Contributor

Here's some data from the HVAC lab that does show supply air Tdp is lower than T dry-bulb. The TXV modulates the refrigerant outlet temperature and superheat varies from around 5F to 13F.

image

@mjwitte mjwitte changed the title Better humidity control for chilled water coils Better humidity control for chilled water coils and for AirloopHVAC:UnitarySystem Mar 18, 2019
@mjwitte mjwitte requested review from Myoldmopar and rraustad March 18, 2019 21:09
@mjwitte
Copy link
Contributor Author

mjwitte commented Mar 18, 2019

@Myoldmopar @rraustad This is ready for review. See diffs discussion at top of PR.

@rraustad
Copy link
Contributor

rraustad commented Mar 20, 2019

7001 looks good.

image

// Turn on humdity control and restart controller
IsConvergedFlag = false;
thisController.HumRatCtrlOverride = true;
if (thisController.Action == iReverseAction) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems redundant but I'm OK with it. Controller should spit out warnings that it can't control temperature much less humidity.

@@ -10574,7 +10574,9 @@ namespace UnitarySystems {
(this->m_TESOpMode == PackagedThermalStorageCoil::OffMode ||
this->m_TESOpMode == PackagedThermalStorageCoil::ChargeOnlyMode)) {
PartLoadFrac = 0.0;
} else {
} else if (!SensibleLoad) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Highlights an issue with all coils types when no sensible load exists and a latent load does. Logic at top of function could skip sensible PLR calcs and go directly to latent calcs. Sensible calcs are inside of if(SensibleLoad || LatentLoad) block.

@@ -252,6 +252,9 @@ TEST_F(EnergyPlusFixture, DXCoils_Test1)
DXCoilPartLoadRatio.allocate(1);
DXCoilFanOpMode.allocate(1);

DataLoopNode::Node.allocate(1);
DXCoil(CoilIndex).AirOutNode = 1;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, previously no Node calls inside the Calc routine, I wouldn't have guessed that but I guess Init sets up node data variables and uses them in Calc. Wonder what the node data variable shows in the Calc routine. Oh well, unit test passes what it's intended to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the condenser inlet node, CalcDoe2DXCoil doesn't read or write to any nodes. It uses variables like DXCoil(DXCoilNum).InletAirTemp.

ReportSizingManager::GetCoilDesFlowT(sysNum, CpAir, designFlowValue, designExitTemp);
EXPECT_FALSE(has_err_output(true));
EXPECT_DOUBLE_EQ(DataSizing::FinalSysSizing(1).CoolSupTemp, designExitTemp);
EXPECT_DOUBLE_EQ(0.002, designFlowValue);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Must be some 0's in the data used to calculate designFlowValue = 0.002, but it passes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Umm, this shouldn't be in here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wait - never mind - all good here. Forgot what was in here.

Copy link
Contributor

@rraustad rraustad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks good. Reviewed code and unit tests.

// early in simulation before plant loops are setup and found
a_node.MassFlowRate = CompFlow;
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This must have fixed something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And neither should this be here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh- right - this fixed an array bounds problem. d136c4c
@rraustad Thanks for the review and merge.

@rraustad
Copy link
Contributor

@mjwitte @jmarrec @Myoldmopar my fault for not closing the issues, however, if the description had one of these keywords then those issues closed just now would have automatically closed when the PR was merged. I was getting used to that happening and forgot to check to make sure the issues were closed when the PR was merged. "Addresses" is not one of those keywords.

@mjwitte
Copy link
Contributor Author

mjwitte commented Mar 26, 2019

Yeah, well, sometimes I don't like the automatic closing, but I suppose I should conform.

@rraustad
Copy link
Contributor

I have no problem with closing issues as we have in the past. I just thought from recent past experience that we were doing it this way now and mistakenly thought those issues would automatically close. Do it either way, I just have to be vigilant to always check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Defect Includes code to repair a defect in EnergyPlus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants