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

I have a question that I hope turns into a discourse about best practices and the future of modeling with Pollination.

Currently, the promise of Pollination CAD is that you can make energy models more quickly and with greater fidelity than before. Revit Pollination produces models with thermal zones (rooms) for every room/space in Revit. This is also incredibly easy to do in Rhino CAD.

Energy modeling best practices have suggested for a while to combine similar spaces with the same internal gains and external orientation. However, these combined zones do not align well with Load Calculations that often want every space modeled for ventilation calculations and diffuser sizing.

The primary problem with modeling every space is that it significant increases model translation and simulation times. I recently worked on a 125,000 ft2 model with 500 rooms that took over 3 hours to simulate and took over an hour just to translate from Honeybee to OpenStudio. When I ran it through the OpenStudio Baseline Measure it took 21 hours!

So here are my questions for the community:

  • How do we balance rooms and thermal zones in Pollination for both Load Calculations and Annual Energy Simulations?
  • What are your best practices for thermal zoning when using Pollination Revit?
  • What about Pollination Rhino?
  • Would a component in Grasshopper or a method in Pollination for combining Rooms into Thermal Zones help with align with mechanical zoning, while also reducing simulation time?
  • What are your best practices for Rooms in Pollination?

Additionally, I would love any feedback on my model set up for the recent project stated previously. This model was incredibly slow and really hampered energy estimates for a recent deadline. Let me know if you have any feedback, here is the model:

20230222 Proposed Model.hbjson (5.5 MB) (606.4 KB)


Thanks, @justinshultz ,

You don’t have to be so subtle with what you’re asking for here. I can tell that you essentially want a separation of Space objects from Zone objects like OpenStudio. In fact, I kinda wish you had put “Space” and “Zone” in the title of the post since it probably would have helped us gauge whether there are more community members who want this. We can definitely bump this up in priority if others chime in about it.

Granted, I am still of the opinion that trying to make “one HBJSON model to rule them all,” which has all of the details that you need for every type of simulation (eg. energy + sizing + daylight + comfort mapping) is just going to fall prey to the same thing that BIM models sometimes fall prey to. That is, you dump so much detail in the model that it takes a very long time to build it and then you can’t iterate easily with it.

This is why we don’t force a certain “Level of Detail” in Pollination modeling practices and we always give you the freedom to make the model as simplified or detailed as you want for the simulation you are trying to run. Then, we offer automated ways of simplifying the model if you need it to run faster for a certain type of simulation. For example, it’s relatively quick to include or exclude the interior shade objects depending on whether you are running a daylight model (where interior geometry is important) or you’re running an energy or sizing simulation (where you don’t want it). Similarly, it’s relatively quick to use the PO_MergeRooms command in the Rhino plugin to merge the smaller rooms (or spaces) into larger rooms (or zones) when you want to run a faster, coarser annual energy simulation. Or, in the Revit plugin, you have the option to either export the model using area polygons around the Rooms (suitable for coarser annual energy simulations) or you can export it using the individual Room geometries (suitable for sizing calculations). So this is our general philosophy and we’re likely to continue to offer solutions of this type.

This is also why I feel strongly that we should never be forcing people to distinguish Zones and Spaces the way OpenStudio does since the reality is that there are many simulations that don’t require this distinction and it just ends up being a barrier to easily editing and iterating with the model. Moreover, Zones don’t have a universally agreed-upon geometric meaning and they are instead defined by abstract things like load profiles and how those loads can be met with a particular HVAC system. Each engineer has their own philosophy about what things can be grouped in the same Zone and different HVAC systems follow different zoning patterns. As a case in point, the zones that I would use if I were retrofitting my house with VRF/Mini-split systems are very different from the zones I would use if I was just planning to use the existing baseboards and replace the boiler with a ASHP supplying hot water. So I think that requiring a Zone definition or overly favoring the use of Zones as the way to organize the model instead of automated methods for merging or splitting rooms is ultimately going to lead to less flexibility with swapping out the HVAC system templates, which is something we’re committed to supporting in Pollination.

Now, with all of that out of the way, I am open to supporting an optional thermal_zone property for Rooms that works similarly to the story property. It would basically be an identifier in Honeybee schema and Rooms that had this same thermal_zone identifier would be grouped into the same OpenStuido ThermalZone upon translation, with each Room being a separate Space. In the absence of any specified thermal_zone, each room just gets its own space and zone just like it does now, keeping the current flexibility avilable. During the translation process, we would take care of averaging the setpoint and ventilation schedules together if they were different for the Rooms apart of the same Zone. This way, the zone is not an object that needs to be reconstructed with setpoints and ventilation every time that you want to try a different HVAC system. You can just change the IDs and you’re set. Similarly, we’d offer automated commands and export options that let you remove all of the thermal_zone IDs so that you can export your sizing model.

If you confirm that this would give you what you want, I’ll put it on our future “To-Do” list and, if I get more people posting here that they would want this, I can bump it up in priority.


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.

:warning: 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. :point_down:

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.


Thanks @mostapha ,

As long as we implement these extra hierarchies with optional identifiers assigned to Rooms and not whole required objects with their own properties (like Honeybee Model or OpenStudio Stories of Zones), I’m in favor of implementing whatever heirarchies people find useful. I know that I was initially a bit adverse to something like Zones or Groups for some of the reasons I have cited above but, now that the base hierarchy of the schema is pretty settled and we’ve made it clear what each of the 5 main honeybee geometry objects means in several BEM interfaces, I’m open to adding other optional additional hierarchy.

Also, I know you’re trying to be abstract by calling them “Groups”. But the concept of “Zones” is already pretty abstract and also widely recognized so I think it may be appropriate. But let’s see what others think here.

1 Like

I think “groups/zones” is a good solution. I could see it being used in other ways, such as grouping spaces where adjacent interior surfaces should be air walls or glass. Makes me wonder if there would be a way to create multiple grouping schemes but probably difficult to standardize in the schema?

Regarding the name, I’m fine with zone, group, or zone group.

Adding to the discussion - having some kind of group/zone feature would be super helpful. I would also be interested in integrating this potential zone/group solution with the .gem file export workflow. So if we’re able to create rooms and define some other grouping level between room and model to represent thermal zones, I’d like to have the option of either exporting the .gem file with rooms OR zones.

Sometimes we have different geometries for different needs as Chris mentioned - I’d create a room-based geometry and export the .gem file for mechanical load calcs in IESVE, then simplify and merge rooms to create another .gem file for energy calcs in IESVE, and have a third model for daylight simulations using LBT (somewhat more simplified, but with added shading details). I usually keep the geometries for thermal comfort studies separate because that tends to focus on one floor or even just a couple spaces. So being able to export two different .gem files for sizing vs energy calcs would streamline the process.

1 Like