-
Notifications
You must be signed in to change notification settings - Fork 396
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
Fix flow rate issue for fanless unitary system #10825
base: develop
Are you sure you want to change the base?
Conversation
// for DX systems, just read the inlet node flow rate and let air loop decide flow | ||
if (this->m_ControlType == UnitarySysCtrlType::Setpoint && this->m_sysType == SysType::Unitary) { | ||
// for systems without a fan, just read the inlet node flow rate and let air loop decide flow | ||
if (this->m_ControlType == UnitarySysCtrlType::Setpoint && this->m_sysType == SysType::Unitary && this->m_FanExists) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this will work as expected. 1) if it's scheduled off it won't turn off at line 942?, 2) if the control zone is in the deadband the air flow should change to the no load flow at line 936/938 but that can't happen when using constant fan (which is used for Setpoint control) and the no load flow = 0, and 3) what if the unit does have a fan?. So I think you want to move the && this->m_FanExists
down to lines 936 (shown) and 938. The tests are if it can turn off when scheduled off, turn back on after flow = 0, and fixes the defect. And then what kind of warning if any to report for this configuration of no fan and no load flow = 0.
if (this->m_FanExists && this->MaxNoCoolHeatAirMassFlow > 0.0) {
state.dataLoopNodes->Node(this->AirInNode).MassFlowRate = this->MaxNoCoolHeatAirMassFlow;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, lines 936 and 938 are duplicates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does my suggestion matter if a fan is present? If it's in the deadband or load is opposite to that unitarysystem and that unitary system does have a fan, should it turn off if there is a down stream system? This seems tricky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just use the no flow check at line 936 and wait for the next defect?
if (this->MaxNoCoolHeatAirMassFlow > 0.0) {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does my suggestion matter if a fan is present? If it's in the deadband or load is opposite to that unitarysystem and that unitary system does have a fan, should it turn off if there is a down stream system? This seems tricky.
It didn't seem tricky to me. If the unitary system doesn't have a fan, in my simple view it should not be touching mass flow rates. It should behave like CoilSystem:*:*. Or do we promise somewhere that a fanless unitary system should control a fan elsewhere on the branch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think at the very least the unit should turn off if not available and this is independent of a fan? Whether that is an issue with a down stream component or not is a question of coordination of availability managers. I guess another option is to modify this text and docs, where "off" only refers to capacity. With the current change I don't think the unit will ever turn off if desired (how does it turn on?, maybe FirstHVACIteration turns it on?) but then you could always schedule the fan for this configuration. I guess if this meets the current need and doesn't break anything then just forge ahead.
AirLoopHVAC:UnitarySystem,
A5, \field Availability Schedule Name
\type object-list
\object-list ScheduleNames
\note Availability schedule name for this system. Schedule value > 0 means the system is available.
\note If this field is blank, the system is always available.
\note A schedule value greater than zero (usually 1 is used) indicates that the unit is
\note available to operate as needed. A value less than or equal to zero (usually zero
\note is used) denotes that the unit must be off.
Fan:SystemModel,
A2 , \field Availability Schedule Name
\note Availability schedule name for this fan. Schedule value > 0 means the fan is available.
\note If this field is blank, the fan is always available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The availability schedule is checked again in controlCoolingSystemToSP
https://github.com/NREL/EnergyPlus/blob/4a17be908304e8ca2266863e76a7f790f2fcca19/src/EnergyPlus/UnitarySystem.cc#L12195-L12198
and in controlHeatingSystemToSP
https://github.com/NREL/EnergyPlus/blob/4a17be908304e8ca2266863e76a7f790f2fcca19/src/EnergyPlus/UnitarySystem.cc#L14011-L14014
and in controlSuppHeatSystemToSP
https://github.com/NREL/EnergyPlus/blob/4a17be908304e8ca2266863e76a7f790f2fcca19/src/EnergyPlus/UnitarySystem.cc#L14649-L14651
so I think the availability schedule question is covered. Without a fan, the unitary system is just a coil wrapper, so if it's off it should just pass through flow and conditions.
EXPECT_EQ(thisSys->m_CoolingSpeedNum, 0); | ||
EXPECT_EQ(state->dataLoopNodes->Node(thisSys->AirInNode).MassFlowRate, 1.2); | ||
EXPECT_EQ(state->dataLoopNodes->Node(thisSys->AirInNode).MassFlowRate, state->dataLoopNodes->Node(thisSys->AirOutNode).MassFlowRate); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does appear to work as expected.
@mjwitte it has been 16 days since this pull request was last updated. |
@mjwitte it has been 7 days since this pull request was last updated. |
Pull request overview
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.