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.
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.
