Model Geometry Discussion: Balancing Model Details and Rooms for Load Calculations versus Energy Modeling

[mostapha]

Thank you, @justinshultz for bringing up this question. I agree with @chriswmackey’s comments. I have a slightly different proposal on how it can be implemented though.

I want to link to the discussion that we had earlier about this topic.

DetailedHVAC Component does not apply Ironbug system

Hi @justinshultz, glad that it worked out. @mingbo and I were worried that we hit a bug in the OpenStudio SDK that we can’t get around it. It was a relief to know that wasn’t the issue. This is a good problem to have! It reminds me of the time that we figured out how to run large parametric studies and then we didn’t know how to make sense of the results. That challenge resulted in building the design explorer UI. I have that discussion bookmarked since you posted it. I was trying to…

DetailedHVAC Component does not apply Ironbug system

I really like the idea of having routines for simplifying the model automatically. This aligns well with the Pollination model we would be getting out of Revit too, as simplification could be automated. I’m thinking of future workflows where our engineers would use Revit Pollination and the Web app to run their load calculations. Yes, I am aware of PO_MergeRooms but the process is destructive. Unmerging the rooms later would be time intensive. I would love a process where I could keep the roo…

DetailedHVAC Component does not apply Ironbug system

That is the goal! It will take some time but we will get there, eventually. Makes sense! This needs the implementation of a new concept in the schema. Let us think about it and see what would be the best approach here. cc: @chriswmackey and @mingbo

---

And before I write my thoughts I should note that I’m just writing my ideas here as part of the discussion. There is no guarantee that we can implement them or that we will implement them.

---

One of the advantages of writing several translators for other simulation software was to be introduced to a few concepts like building bodies, groups, and blocks. They are all concepts for adding levels of abstraction to the model. I think we can use similar concepts.

Right now we have two levels of abstraction: Building/Model and Room. Model is where we assign the global values and room is where we let the user overwrite those global values. These concepts are not geometrical and are only used for properties.

I think we can have a more layered hierarchy to help abstract the models, and we have the core functionalities to get this to work for models with extruded walls.

Stories and groups

I think we can use story and group as two properties that can help with grouping rooms. Similar to model or room we should be able to assign properties to a story or a group. In addition, we can abstract the geometry by trying to merge the rooms in a story or a group based on the user input. For instance, the user can create a new model from the existing model where the abstraction level is story.

Model.to_hbjson(..., abstraction_level='story')

This is what a model can look like with 3 different abstraction levels.

This way we keep the original rooms in the model and provide simplified representations of the model which should address the concern that @justinshultz raised in the other thread.

@justinshultz

Yes, I am aware of PO_MergeRooms but the process is destructive. Unmerging the rooms later would be time intensive. I would love a process where I could keep the rooms separate for engineering load calculations and then simplified for annual energy simulations.

Additional notes

• I don’t know what happens to HVAC and if we allow assigning an HVAC system to a story or a group but for other properties like program types we can create an average version similar to what we already do in a Dragonfly model.

• This is not the same but we have a similar concept for aperture groups where one can group the apertures together and then assign properties to the group.