-
Notifications
You must be signed in to change notification settings - Fork 17
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
Whole building Common Spaces #1850
base: master
Are you sure you want to change the base?
Conversation
…o whole_building_common_spaces
HPXMLtoOpenStudio/resources/model.rb
Outdated
@@ -779,21 +779,38 @@ def self.merge_unit_models(model, hpxml_osm_map) | |||
end | |||
end | |||
|
|||
hpxml_osm_map.values.each_with_index do |unit_model, unit_number| | |||
unit_surface_to_obj_index_map = {} # map of unit model surface handle to whole building model object index |
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.
@shorowit Sadly that there's not a better solution to keep the surface-to-surface mapping information while knowing the handles after merging unit models (and I cannot do it in front, by assigning a surface in another model space as adjacent surface). The only solution I can think of here is to use the indexes after calling model.addObjects. OS source codes specifically call out that the order will be kept, so it's fine for now, but we need to be careful if this is called more than once in the future.
Tried a hundred times and this one seems to be working, still pretty promising!
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.
Great to see some progress! A couple initial questions/thoughts.
# Need to set the same construction to make OS working | ||
adjacent_surface.setConstruction(surface.construction.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.
I forget, did we discuss a plan for ensuring constructions are identical for the two walls that point to each other?
For shared boilers, I was proposing that one would describe the shared boiler once (in the first dwelling unit attached to it, e.g. here), and then every other dwelling unit would have a boiler with the sameas
attribute where no additional details would be provided (e.g., here) so as to prevent inconsistency. If we went that path, ideally we could enforce it via the Schematron validation. Is that the path you're going to go? Or did you have another idea in mind?
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.
Yes that's what I think, add more error-checking in EPvalidator to make sure there's no inconsistent construction, did you disallow the boiler inputs when using sameas? I can do the same restriction or I can check the constructions are exactly the same.
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 remember if I got that far with the shared boiler implementation, but I would favor disallowing the inputs.
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.
Checked the links, it seems that you disallowed additional inputs, I'm going to do the same.
The approach seems working! 🎉 Going to make this PR more concrete next. |
Pull Request Description
Checklist
Not all may apply:
EPvalidator.xml
) has been updatedopenstudio tasks.rb update_hpxmls
)HPXMLtoOpenStudio/tests/test*.rb
and/orworkflow/tests/test*.rb
)openstudio tasks.rb update_measures
has been run