-
Notifications
You must be signed in to change notification settings - Fork 193
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
AirLoopHVACUnitarySystem set Method During XXX Operation #4873
Conversation
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.
Shouldn't the setSupplyAirFlowRateMethodDuringCoolingOperation
/ resetSupplyAirFlowRateMethodDuringCoolingOperation
etc should be marked deprecated and become no-op?
ideally the boost::optional<std::string> supplyAirFlowRateMethodDuringCoolingOperation()
getter should have an API-breaking change and return a std::string
instead too in that case.
@jmarrec You're advocating for introducing
And then API-breaking the getters as well as deprecating the setters (and resetters)? |
@joseph-robertson If they end up being always defined, then yes I guess that's what I'm suggesting. But I'm fine if we don't do it. Still, the setters/resetters should probably be deprecated if we mean for others setters to set it and it's deterministic (I haven't checked if that's the case), meaning that there isn't a use case for calling the setter manually to do something else. A counter example would be a ChillerElectricEIR's condenser Type: "AirCooled", "WaterCooled", "EvaporativelyCooled". If you connect to a PlantLoop, you can set it to WaterCooled. If you disconnect, you can set it to AirCooled. But the user still has a use case for calling |
I think Click to expandThe default value should have been From the IDD:
I suppose we could have had no resetter. Ctor would harcode to |
…itary-sys-opmethod2
…itary-sys-opmethod2
AirLoopHVACUnitarySystem set Method During XXX Operation - option, 2
AirLoopHVACUnitarySystem set Method During XXX Operation - option
@@ -106,7 +108,7 @@ namespace model { | |||
boost::optional<HVACComponent> supplementalHeatingCoil() const; | |||
|
|||
/** In EnergyPlus 8.3.0 and above this property maps to the EnergyPlus field "Cooling Supply Air Flow Rate Method" **/ | |||
boost::optional<std::string> supplyAirFlowRateMethodDuringCoolingOperation() const; | |||
std::string supplyAirFlowRateMethodDuringCoolingOperation() const; |
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.
Can we capture this API change for the release notes? @DavidGoldwasser or @tijcolem do we have a place to keep track of these so we don't miss them at release time?
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.
Capturing API changes in release notes here: 52b5d43
@@ -84,12 +84,14 @@ namespace model { | |||
|
|||
boost::optional<Schedule> supplyAirFanOperatingModeSchedule() const; | |||
|
|||
bool hasHeatingCoil() const; // For speed |
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.
These are in the impl so I probably shouldn't care. (not that I do) Curious though, what is the purpose of this over just asking for the ::heatingCoil which is optional and therefore behaves a lot like a bool?
CI Results for 52b5d43:
|
Pull request overview
Supply Air Flow Rate Method During <XXX> Operation
should be set via related setters/autosize #4695Pull 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.