Allow multistage electric coil to be supplemental coil of UnitarySystem#9414
Allow multistage electric coil to be supplemental coil of UnitarySystem#9414
Conversation
src/EnergyPlus/UnitarySystem.cc
Outdated
|
|
||
| HeatingCoils::CalcMultiStageElectricHeatingCoil(state, CoilIndex, SpeedRatio, CycRatio, SpeedNum, FanOpMode, QActual); | ||
|
|
||
| Residuum = Par[2] - QActual; |
There was a problem hiding this comment.
Usually these RootSolver functions return a fraction of load met, e.g., (Par[2] - QActual)/Par[2]. If the tolerance is 0.001 then that means with this math the RootSolver function will iterate to within 0.001 W. That's OK for heating coils most of the time because heating coils usually return the exact load request.
|
Those diffs in the html show a change in ventilation. That probably means a change in supply air flow rate. You can compare SA and OA flow rate between this branch and develop and see if those show a change in operation. |
src/EnergyPlus/UnitarySystem.cc
Outdated
| SuppPLR = this->m_SuppHeatPartLoadFrac; | ||
| // only need to test for high supply air temp if supplemental coil is operating | ||
| if (SuppPLR > 0.0) { | ||
| if (SupHeaterLoad > 0.0 && this->m_DesignSuppHeatingCapacity > 0.0) { |
There was a problem hiding this comment.
This change might be why there are diffs. I would revert this logic unless there is good reason for it. The cooling and heating coil are modeled first to determine the air flow rate and PLRs. If after that the supp heater is needed, then SuppPLR will be > 0 and the supp heater will turn on. Also, if (... && this->m_DesignSuppHeatingCapacity > 0.0), of course it is.
There was a problem hiding this comment.
Changes to this part are needed to allow multistage backup coils, but I will try reverting the logic to be as close to previous one as possible for other cases.
There was a problem hiding this comment.
You could use something like this (here and other places) just to get it to work and we can figure out better logic later. There should be no diffs from adding a coil that doesn't exist yet.
if (this->m_SuppCoilExists) {
if( stagedheatingcoil) {
insert your logic
} else {
existing code
}
}
|
|
||
| auto &HeatingCoil(state.dataHeatingCoils->HeatingCoil); | ||
| auto &heatingCoil = state.dataHeatingCoils->HeatingCoil(CoilNum); |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
| HeatingCoil(CoilNum).HeatingCoilLoad = MSHPMassFlowRateHigh * (HSFullLoadOutAirEnth - InletAirEnthalpy) * SpeedRatio + | ||
| MSHPMassFlowRateLow * (LSFullLoadOutAirEnth - InletAirEnthalpy) * (1.0 - SpeedRatio); | ||
| ElecHeatingCoilPower = heatingCoil.ElecUseLoad; | ||
| heatingCoil.HeatingCoilLoad = TotCapHS * SpeedRatio + TotCapLS * (1.0 - SpeedRatio); |
There was a problem hiding this comment.
I am trying to find a reason for the diff in _MultiSpeedACElecFurnace.idf. That example file uses AirLoopHVAC:UnitaryHeatPump:AirToAir:MultiSpeed (no changes) with Coil:Heating:Electric:MultiStage so it must be some change in HeatingCoils that changed that answer. It looks like these are the same but I wonder if there is a rounding difference that causes the diff. Have you plotted SA and OA air flow rate and heating coil rate to see if they are very similar?
There was a problem hiding this comment.
Note that I have quickly fixed two lines of codes: https://github.com/NREL/EnergyPlus/pull/9414/files/78461457cb705a42f132d0c8037c1f66401dbba8#diff-a4469a58b3b57ae5c4916cb9efb12f0c6ef79224175d09c796a7f6c2e1d3ec33R9039
and:
https://github.com/NREL/EnergyPlus/pull/9414/files/78461457cb705a42f132d0c8037c1f66401dbba8#diff-a4469a58b3b57ae5c4916cb9efb12f0c6ef79224175d09c796a7f6c2e1d3ec33R15991
These two lines looked pretty clear to be bugs, but they might cause diffs. I will revert them and see whether that's the case.
There was a problem hiding this comment.
If you find actual bugs during development you should open a new issue and put those few lines in a seperate PR and then get that PR merged. Then when you pull develop those diffs, related to that necessary change, will be gone. And the defect documented with an issue and PR specific to that bug.
src/EnergyPlus/HeatingCoils.cc
Outdated
| OpMode); // Autodesk:OPTIONAL SpeedRatio, PartLoadRatio, StageNum used without PRESENT check | ||
| } else if (state.dataHeatingCoils->HeatingCoil(CoilNum).HCoilType_Num == Coil_HeatingGasOrOtherFuel) { | ||
| OpMode, | ||
| QCoilActual2); // Autodesk:OPTIONAL SpeedRatio, PartLoadRatio, StageNum used without PRESENT check |
There was a problem hiding this comment.
Regarding diffs, the other change I see is you are now passing &QCoilActual so I am wondering if this fixed something now that the Calc function has more information.
| latOut); | ||
| // check that heating coil air outlet node is at maximum supply air temperature | ||
| // | ||
| // This is not passing because main heating coil is not limited by Maximum Supply Temperature correctly. |
There was a problem hiding this comment.
@rraustad Please see this. I have fixed the maximum supply air issue on supp coil side, but the main coil is still not correct. It is because the recalculated loads are not used in calcUnitaryHeatingSystem so the PLR is not recalculated.
I changed the unitary system parent object in the newly added test file, so the existing test file is possible to operate differently.
There was a problem hiding this comment.
Yeah, that's OK. The main heating coil does not limit coil outlet air temp. And if sized properly should not present high outlet temps. This is the reason I suggested autosizing this file since the Sizing:Zone object has a supply air temp input. With these final changes I think this is ready to merge but I will make a final pass to make sure.
src/EnergyPlus/UnitarySystem.cc
Outdated
| if (this->m_NumOfSpeedSuppHeating > 0) { | ||
| this->calcMultiStageSuppCoilStageByLoad(state, MaxHeatCoilLoad, FirstHVACIteration); | ||
| } | ||
| this->calcUnitarySuppHeatingSystem(state, FirstHVACIteration, SuppPLR, MaxHeatCoilLoad); |
There was a problem hiding this comment.
This is the call that bothers me. To call a new supp heater model, and then call the calcUnitarySuppHeatingSystem function to simulate that coil model is redundant. It seems the call to the new coil model can be incorporated into existing calls. This can be resolved later since UnitarySystem needs a major overhaul to clean things up. This is working so well that I hesitate to muck with it now.
|
@yzhou601 this does look good for load based control. I changed the control for the new example file to Setpoint and found an issue. I haven't locked in on an answer yet (#9482 is in play) but RootSolver is calling the DX coil model for the supp MS heating coil. This should be easy to resolve. The new example file is SingleFamilyHouse_TwoSpeed_MultiStageElectricSuppCoil_SPControl, |
|
Warning is addressed in #9482. The problem with set point control is here where the heating coil is called instead of the supp heater. and here |
src/EnergyPlus/UnitarySystem.cc
Outdated
| } | ||
| LatLoad = 0.0; | ||
| this->m_FanOpMode = 1; // why is this here? | ||
| // this->m_FanOpMode = 1; // why is this here? |
|
Added issue #9484 to address control issue with Coil:Cooling:DX:MultiSpeed. See top left figure above for new example file using set point control. |
…ow_multistage_backup_coil
|
@rraustad Thanks for fixing a few issues, these commits look good to me. Good catch! |
|
Unit tests run clean locally. Warnings in err file are described in #9484 and should be cleaned up with that effort. Expect CI to be all green. |
|
This all looks good, CI is green. There is a little time before merging for anyone to look over this. |
Myoldmopar
left a comment
There was a problem hiding this comment.
I left a few comments in here. In general, these changes are exactly what I would expect for this new capability. The two things I mentioned that could be address are not related to algorithmic changes:
- In format statements we shouldn't create
std::stringobjects as args unnecessarily - Your new residual functions mimic the existing residual functions, and they are a bit more verbose than necessary.
I don't actually think that either of these necessitate additional commits on their own. If any other commits are needed, please address these as part of that.
|
Thanks @Myoldmopar , pushed a cleanup commit that addressed your comments. |
|
This branch is 25 commits behind develop and diff is from SurfLWR example file. No need to run another CI cycle. |
| PartLoadRatio = HeatPLR; | ||
| } else if (state.dataGlobal->DoCoilDirectSolutions && state.dataUnitarySystems->HeatingLoad && | ||
| this->m_HeatingCoilType_Num == DataHVACGlobals::CoilDX_MultiSpeedHeating) { | ||
| this->m_CoolingCoilType_Num == DataHVACGlobals::CoilDX_MultiSpeedHeating) { |
There was a problem hiding this comment.
@rraustad Hi, Richard, just want to point out that in this commit I reverted two lines of codes to eliminate changes unrelated to my added feature. But these two lines look very suspicious, could you double check if these are bugs?
There was a problem hiding this comment.
Actually, this one was here before this branch.
src/EnergyPlus/UnitarySystem.cc
Outdated
| FanOpMode = int(Par[6]); | ||
|
|
||
| HeatingCoils::CalcMultiStageGasHeatingCoil(state, CoilIndex, SpeedRatio, CycRatio, SpeedNum, FanOpMode); | ||
| HeatingCoils::CalcMultiStageElectricHeatingCoil(state, CoilIndex, SpeedRatio, CycRatio, SpeedNum, FanOpMode, QActual); |
There was a problem hiding this comment.
Yes, this also looks wrong.
case DataHVACGlobals::Coil_HeatingGas_MultiStage: {
CycRatio = Par[4];
SpeedNum = int(Par[5]);
FanOpMode = int(Par[6]);
HeatingCoils::CalcMultiStageElectricHeatingCoil(state, CoilIndex, SpeedRatio, CycRatio, SpeedNum, FanOpMode, QActual, SuppHeat);
There was a problem hiding this comment.
I agree, these bugs were here before this branch.
There was a problem hiding this comment.
This one appears to have been correct and is now incorrect.
There was a problem hiding this comment.
They are both bugs at this point.




Pull request overview
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.