-
Notifications
You must be signed in to change notification settings - Fork 185
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
Addresses #4941, wrap DistrictHeating:Steam #4954
Conversation
@@ -13,6 +13,8 @@ namespace openstudio { | |||
|
|||
namespace model { | |||
|
|||
class Schedule; | |||
|
|||
namespace detail { | |||
|
|||
class DistrictHeating_Impl; |
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 am very tempted to rename the class to DistrictHeatingWater
and IDD Object too, to avoid the same fiasco as WaterHeaterHeatPump, which should be WaterHeatHeatPumpPumped since the WaterHeaterHeatPumpWrappedCondenser was added later.
We can provide an alias for backward compatibility... Same as what we did for AirTerminalSingleDuctUncontrolled => AirTerminalSingleDuctConstantVolumeNoReheat (it's perhaps time to remove it now that I think abouve 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 not opposed if there is an alias. Is there a precedent for alias on Model types anywhere else? Certainly we have them for fields/methods, but I'm not sure about types.
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 have made that change in #4972. Fully aliased, with a deprecated message in both C++, as well bindings (Ruby and Python)
Yes, we have a precedent, AirTerminalSingleDuctUncontrolled -> AirTerminalSingleDuctConstantVolumeNoReheat. Which we have since 2.7.0 and we should definitely remove now.
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.
src/energyplus/ForwardTranslator/ForwardTranslateDistrictHeatingSteam.cpp
Outdated
Show resolved
Hide resolved
src/energyplus/ForwardTranslator.cpp
Outdated
@@ -3497,6 +3502,7 @@ namespace energyplus { | |||
IddObjectType::OS_Table_Lookup, | |||
IddObjectType::OS_DistrictCooling, | |||
IddObjectType::OS_DistrictHeating, | |||
IddObjectType::OS_DistrictHeating_Steam, |
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 don't. This object should only be translated if it's on a plant loop. Same for the other District objects for that matter.
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 commented out these 3. Is that enough?
A5 ; \field Capacity Fraction Schedule | ||
\note Schedule values are multiplied by Nominal Capacity for current capacity | ||
\type object-list | ||
\object-list ScheduleNames |
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.
- Required field, ctor set to alwaysOnContinuousSchedule?
- Or is it better to follow the API of the two similar objects.
(in fact, DistrictHeating:Water, DistrictCooling, and DistrictHeating:Steam are exactly the same, and E+ uses a common routine to get their input).
@kbenne thoughts?
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 gut is make DistrictHeating::capacityFractionSchedule and DistrictHeatingSteam::capacityFractionSchedule since both are new fields and I really hope we can reduce optionals as much as possible. Then I guess the question is do we make this required in the IDD? I think yes, but then we need to do version translation for the existing DistrictHeating type. I suppose the alternative would be to handle it in the API and return a default schedule if the osm does not define one, but I'm guessing that is not a popular option.
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 can make them non optional, in the new PR #4972 if we think that's better. VT isn't that complicated.
CI Results for 431293d:
|
A5 ; \field Capacity Fraction Schedule | ||
\note Schedule values are multiplied by Nominal Capacity for current capacity | ||
\type object-list | ||
\object-list ScheduleNames |
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 gut is make DistrictHeating::capacityFractionSchedule and DistrictHeatingSteam::capacityFractionSchedule since both are new fields and I really hope we can reduce optionals as much as possible. Then I guess the question is do we make this required in the IDD? I think yes, but then we need to do version translation for the existing DistrictHeating type. I suppose the alternative would be to handle it in the API and return a default schedule if the osm does not define one, but I'm guessing that is not a popular option.
@@ -13,6 +13,8 @@ namespace openstudio { | |||
|
|||
namespace model { | |||
|
|||
class Schedule; | |||
|
|||
namespace detail { | |||
|
|||
class DistrictHeating_Impl; |
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 not opposed if there is an alias. Is there a precedent for alias on Model types anywhere else? Certainly we have them for fields/methods, but I'm not sure about types.
Superseded by #4972 (I merged this PR in it) |
…edule) The grand protector of the API has spoken! cf @kbenne 's comment here: #4954 (comment)
Pull request overview
DistrictCooling
DistrictHeating:Water
DistrictHeating:Steam
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.