Skip to content
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

Merged
merged 16 commits into from
Sep 20, 2023

Conversation

joseph-robertson
Copy link
Collaborator

@joseph-robertson joseph-robertson commented Aug 30, 2023

Pull request overview

Pull Request Author

  • Model API Changes / Additions
  • Any new or modified fields have been implemented in the EnergyPlus ForwardTranslator (and ReverseTranslator as appropriate)
  • Model API methods are tested (in src/model/test)
  • EnergyPlus ForwardTranslator Tests (in src/energyplus/Test)
  • If a new object or method, added a test in NREL/OpenStudio-resources: Add Link
  • If needed, added VersionTranslation rules for the objects (src/osversion/VersionTranslator.cpp)
  • Verified that C# bindings built fine on Windows, partial classes used as needed, etc.
  • All new and existing tests passes
  • If methods have been deprecated, update rest of code to use the new methods

Labels:

  • If change to an IDD file, add the label IDDChange
  • If breaking existing API, add the label APIChange
  • If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • Code Style, strip trailing whitespace, etc.
  • All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
  • Labeling is ok
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified

@joseph-robertson joseph-robertson added Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge. IDDChange labels Aug 30, 2023
@joseph-robertson joseph-robertson self-assigned this Aug 30, 2023
@joseph-robertson joseph-robertson mentioned this pull request Aug 29, 2023
26 tasks
src/model/ScheduleTypeRegistry.cpp Outdated Show resolved Hide resolved
src/model/test/DistrictCooling_GTest.cpp Show resolved Hide resolved
src/model/test/DistrictHeatingSteam_GTest.cpp Show resolved Hide resolved
src/model/test/DistrictHeating_GTest.cpp Show resolved Hide resolved
@@ -13,6 +13,8 @@ namespace openstudio {

namespace model {

class Schedule;

namespace detail {

class DistrictHeating_Impl;
Copy link
Collaborator

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)

Copy link
Contributor

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.

Copy link
Collaborator

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -3497,6 +3502,7 @@ namespace energyplus {
IddObjectType::OS_Table_Lookup,
IddObjectType::OS_DistrictCooling,
IddObjectType::OS_DistrictHeating,
IddObjectType::OS_DistrictHeating_Steam,
Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Comment on lines +16702 to +16705
A5 ; \field Capacity Fraction Schedule
\note Schedule values are multiplied by Nominal Capacity for current capacity
\type object-list
\object-list ScheduleNames
Copy link
Collaborator

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?

Copy link
Contributor

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.

Copy link
Collaborator

@jmarrec jmarrec Sep 19, 2023

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.

Comment on lines +16702 to +16705
A5 ; \field Capacity Fraction Schedule
\note Schedule values are multiplied by Nominal Capacity for current capacity
\type object-list
\object-list ScheduleNames
Copy link
Contributor

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;
Copy link
Contributor

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.

@jmarrec
Copy link
Collaborator

jmarrec commented Sep 19, 2023

Superseded by #4972 (I merged this PR in it)

jmarrec added a commit that referenced this pull request Sep 20, 2023
…edule)

The grand protector of the API has spoken! cf @kbenne 's comment here: #4954 (comment)
@jmarrec jmarrec merged commit 7a3a5ab into v23.2.0-IOFreeze Sep 20, 2023
0 of 4 checks passed
@joseph-robertson joseph-robertson linked an issue Sep 27, 2023 that may be closed by this pull request
@jmarrec jmarrec deleted the district-heating-steam branch January 15, 2024 09:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
IDDChange Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

E+ 23.2.0: Wrap DistrictHeating:Steam
4 participants