-
Notifications
You must be signed in to change notification settings - Fork 192
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
ZoneHVAC:*: new Design Specification Multispeed Object fields #4964
base: develop
Are you sure you want to change the base?
Conversation
if (auto designSpec = designSpecificationMultispeedObject()) { | ||
wahpClone.setDesignSpecificationMultispeedObject(designSpec->clone(model).cast<UnitarySystemPerformanceMultispeed>()); | ||
} |
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.
Ok, AirLoopHVACUNitarySystem already clones / remove, so let's do the same
@@ -432,6 +434,18 @@ namespace energyplus { | |||
} | |||
} | |||
|
|||
// Design Specification Multispeed Object Name |
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 don't see any FT testing for this one?
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.
@jmarrec I didn't get too far on this PR yet. I sort of got tripped up on FT. Appears that for AirLoopHVACUnitarySystem, it FTs the UnitarySystemPerformanceMultispeed object, but also creates one if one doesn't exist. Under what conditions should we create one for ZoneHVACWaterToAirHeatPump and ZoneHVACTerminalUnitTVariableRefrigerantFlow?
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.
AirLoopHVACUnitarySystem I believe throws if you use multispeed / variable speed coils without a UnitarySystemPerformanceMultispeed object, hence why the FT creates one if needed.
I'm not 100% sure whether the VRF TU and the ZoneHVAC:WaterToAirHeatPump have the same behavior now. If so, we should create one in FT. In that case, should move the default creation to a helper function so we can reuse in other modules.
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, that's quite confusing, but it seems that this applies not to the coils but to the fans. The original NFP proposed a new object "FanPerformance:Multispeed", but apparently UnistarySystemPerformance:Multispeed was kept.
https://github.com/NREL/EnergyPlus/blob/develop/design/FY2023/NFP_MultispeedFans.md
My understanding is that this is purely optional, regardless of the coils you use for the ZoneHVAC:WAHP or ZoneHVAC:TU:VRF objects. We should probably make some dummy IDF tests to confirm. I'll ask the E+ dev team right now too.
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.
@jmarrec I stubbed UnitarySystemPerformance FT to handle additional coil types CoilXXXWaterToAirHeatPumpEquationFit
, CoilXXXDXVariableRefrigerantFlow
, and CoilXXXDXVariableRefrigerantFlowFluidTemperatureControl
. But I'm a little unclear on how to determine NumberofSpeedsforXXX
. The speeds should not correspond to the coils, but to the supply fan? Are we going to need to create a new setter method for speeds on the UnitarySystemPerformance object?
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.
My earlier post was misleading I think. The object varies the fan airflow in conjunction with the heating/cooling capacity.
So Number of Speeds for Heating should match the heating coil number of speeds, when the coil does have speeds.
I don't think we need to create a UnitarySystemPerformance object for VRF / ZoneHVACWaterToAirHeatPump if they don't throw when one isn't present. In that case, we're just left translating whatever the user chose to specify.
Also, take VRFMultispeedFan.idf
for eg. You have one ZoneHVAC:TerminalUnit:VariableRefrigerantFlow
(TU1
) object with some COIL:Cooling:DX:VariableRefrigerantFlow
and COIL:Heating:DX:VariableRefrigerantFlow
. These coils do not have speed-related fields. Yet there is a UnitarySystemPerformance assigned to it.
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'm looking at VRFMultispeedFan.idf
...
UnitarySystemPerformance:Multispeed,
Sys 1 WaterToAirHP System MultiSpeed Performance, !- Name
2, !- Number of Speeds for Heating
2, !- Number of Speeds for Cooling
Where does the "2" come from? Should this value be hardcoded when coil object types are COIL:*:DX:VariableRefrigerantFlow
?
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.
That is arbitrary I believe.
EXPECT_TRUE(idf_hp.isEmpty(ZoneHVAC_WaterToAirHeatPumpFields::DesignSpecificationMultispeedObjectType)); | ||
EXPECT_TRUE(idf_hp.isEmpty(ZoneHVAC_WaterToAirHeatPumpFields::DesignSpecificationMultispeedObjectName)); |
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.
Please actually assign one and check that it's all good.
CI Results for 73f1545:
|
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 is a tough one and I'm not sure I completely understand how this object is supposed to be used when not in a AirLoopHVAC:UnitarySystem. Maybe we should just punt on this new feature until a bit later after we've merged 23.2.0-IOFreeze to develop?
This does not enable using the object with VRF objects at least (eg, VRFMultispeedFan.idf
is not reproducible). Seems like it'd work for the ZoneHVACWaterToAirHeatPump in most cases though.
For VRF we'd need to expose the Number of Speeds for <Heating|Cooling>
fields nor the <Heating|Cooling> Speed <N> Supply Air Flow Ratio
fields. Which may be problematic for other objects because that means we need to handle the case where what the user manually entered is inconsistent with the VSD coil's number of Speeds.
if (unitarySystems.size() == 1) { | ||
AirLoopHVACUnitarySystem& unitarySystem = unitarySystems[0]; | ||
heatingCoil = unitarySystem.heatingCoil(); | ||
coolingCoil = unitarySystem.coolingCoil(); | ||
} | ||
|
||
if (tuVRFs.size() == 1) { | ||
ZoneHVACTerminalUnitVariableRefrigerantFlow& tuVRF = tuVRFs[0]; | ||
heatingCoil = tuVRF.heatingCoil(); | ||
coolingCoil = tuVRF.coolingCoil(); | ||
} | ||
|
||
if (hps.size() == 1) { | ||
ZoneHVACWaterToAirHeatPump& hp = hps[0]; | ||
heatingCoil = hp.heatingCoil().optionalCast<HVACComponent>(); | ||
coolingCoil = hp.coolingCoil().optionalCast<HVACComponent>(); | ||
} |
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.
if (unitarySystems.size() == 1) { | |
AirLoopHVACUnitarySystem& unitarySystem = unitarySystems[0]; | |
heatingCoil = unitarySystem.heatingCoil(); | |
coolingCoil = unitarySystem.coolingCoil(); | |
} | |
if (tuVRFs.size() == 1) { | |
ZoneHVACTerminalUnitVariableRefrigerantFlow& tuVRF = tuVRFs[0]; | |
heatingCoil = tuVRF.heatingCoil(); | |
coolingCoil = tuVRF.coolingCoil(); | |
} | |
if (hps.size() == 1) { | |
ZoneHVACWaterToAirHeatPump& hp = hps[0]; | |
heatingCoil = hp.heatingCoil().optionalCast<HVACComponent>(); | |
coolingCoil = hp.coolingCoil().optionalCast<HVACComponent>(); | |
} | |
if (unitarySystems.size() == 1) { | |
AirLoopHVACUnitarySystem& unitarySystem = unitarySystems.front(); | |
heatingCoil = unitarySystem.heatingCoil(); | |
coolingCoil = unitarySystem.coolingCoil(); | |
} else if (tuVRFs.size() == 1) { | |
ZoneHVACTerminalUnitVariableRefrigerantFlow& tuVRF = tuVRFs.front(); | |
heatingCoil = tuVRF.heatingCoil(); | |
coolingCoil = tuVRF.coolingCoil(); | |
} else { // if (hps.size() == 1) | |
ZoneHVACWaterToAirHeatPump& hp = hps.front(); | |
heatingCoil = hp.heatingCoil().optionalCast<HVACComponent>(); | |
coolingCoil = hp.coolingCoil().optionalCast<HVACComponent>(); | |
} |
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.
Because of the if (((unitarySystems.size() + tuVRFs.size() + hps.size()) != 1)) {
line above, yes, I think we'd be able to collapse to your suggestion.
} else if (heatingCoil->iddObjectType() == openstudio::IddObjectType::OS_Coil_Heating_DX_VariableSpeed) { | ||
auto heatingCoilDXVarspeed = heatingCoil->cast<CoilHeatingDXVariableSpeed>(); | ||
sysPerf.setInt(UnitarySystemPerformance_MultispeedFields::NumberofSpeedsforHeating, heatingCoilDXVarspeed.speeds().size()); | ||
} else if (heatingCoil->iddObjectType() == openstudio::IddObjectType::OS_Coil_Heating_WaterToAirHeatPump_VariableSpeedEquationFit) { | ||
auto heatingCoilWaterToAirHeatingVar = heatingCoil->cast<CoilHeatingWaterToAirHeatPumpVariableSpeedEquationFit>(); | ||
sysPerf.setInt(UnitarySystemPerformance_MultispeedFields::NumberofSpeedsforHeating, heatingCoilWaterToAirHeatingVar.speeds().size()); | ||
} else { // e.g., CoilHeatingWaterToAirHeatPumpEquationFit, CoilHeatingDXVariableRefrigerantFlow, CoilHeatingDXVariableRefrigerantFlowFluidTemperatureControl |
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.
If you run an AirLoopHVACUnitarySystem (or a ZoneHVACWAHP) with these coils and no UnitarySystemPerformance object, does E+ throw?
Just curious if you tested it, and same question for the below cooling coils below
if (boost::optional<UnitarySystemPerformanceMultispeed> designSpecificationMultispeedObject = modelObject.designSpecificationMultispeedObject()) { | ||
boost::optional<IdfObject> _unitarySystemPerformance = translateAndMapModelObject(designSpecificationMultispeedObject.get()); | ||
|
||
if (_unitarySystemPerformance && _unitarySystemPerformance->name()) { | ||
idfObject.setString(ZoneHVAC_TerminalUnit_VariableRefrigerantFlowFields::DesignSpecificationMultispeedObjectType, | ||
_unitarySystemPerformance->iddObject().name()); | ||
idfObject.setString(ZoneHVAC_TerminalUnit_VariableRefrigerantFlowFields::DesignSpecificationMultispeedObjectName, | ||
_unitarySystemPerformance->name().get()); | ||
} | ||
} |
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 is pointless here for the VRF object, because you don't have a way to set the number of Speeds during Heating/Cooling, and the VRF coils do not bear the requested information to autofill them.
Given what we see in VRFMultispeedFan.idf
that means:
- We actually need to expose the number of heating/cooling speeds
- We also need the extensible portion
<Heating|Cooling> Speed <N> Supply Air Flow Ratio
- We probably need to throw or overwrite when writing for a coil that has an actual number of speeeds
- We probably need to reach out to the E+ devs responsible for this feature to understand it fully. I'm quite fuzzy on how this is used with coils that don't have an actual number of speeds
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.
Couple of things:
(1) I had noticed the "gap" on the heating/cooling speeds - that's why I had posed the question "Are we going to need to create a new setter method for speeds on the UnitarySystemPerformance object?" above.
(2) I thought you had said that the unitary system performance speeds in VRFMultispeedFan.idf
were arbitrary?
But generally speaking, yes, I agree that we should probably punt on this new feature until later.
if (boost::optional<UnitarySystemPerformanceMultispeed> designSpecificationMultispeedObject = modelObject.designSpecificationMultispeedObject()) { | ||
boost::optional<IdfObject> _unitarySystemPerformance = translateAndMapModelObject(designSpecificationMultispeedObject.get()); | ||
|
||
if (_unitarySystemPerformance && _unitarySystemPerformance->name()) { | ||
idfObject.setString(ZoneHVAC_WaterToAirHeatPumpFields::DesignSpecificationMultispeedObjectType, | ||
_unitarySystemPerformance->iddObject().name()); | ||
idfObject.setString(ZoneHVAC_WaterToAirHeatPumpFields::DesignSpecificationMultispeedObjectName, _unitarySystemPerformance->name().get()); | ||
} | ||
} |
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.
Unlike VRF, there are a varierty of coils when we can autofill the Number of Speeds for <Heating|Cooling>
fields nor the <Heating|Cooling> Speed <N> Supply Air Flow Ratio
.
One, or maybe the only one, where we cannot is the CoilHeatingWaterToAirHeatPumpEquationFit, and perhaps that's fine. I'm not 100% sure
Pull request overview
Support new fields "Design Specification Multispeed Object Type" and "Design Specification Multispeed Object Name" for:
ZoneHVAC:WaterToAirHeatPump
ZoneHVAC:TerminalUnit:VariableRefrigerantFlow
Also, add:
UnitarySystemPerformanceMultispeed
FT support forCoilXXXDXVariableSpeed
andCoilXXXWaterToAirHeatPumpVariableSpeedEquationFit
(FT forAirLoopHVACUnitarySystem
supports these coil types but FT forUnitarySystemPerformanceMultispeed
didn't previously)UnitarySystemPerformanceMultispeed_GTest.cpp
FT test file for translatingUnitarySystemPerformanceMultispeed
onAirLoopHVACUnitarySystem
,ZoneHVACWaterToAirHeatPump
, andZoneHVACTerminalUnitVariableRefrigerantFlow
Pull Request Author
src/model/test
)src/energyplus/Test
)src/osversion/VersionTranslator.cpp
)Labels:
IDDChange
APIChange
Pull Request - Ready for CI
so that CI builds your PRReview Checklist
This will not be exhaustively relevant to every PR.