Can Pollination model multiple Spaces in one Zone?
The term “Room” which is used in Pollination Rhino Plugin is confusing. Zone and Space are used in EnergyPlus.
If users create a Room with the ID “Room001” in Pollination, it is modelled as a Zone named “Room001” and a Space named “Room001_Space” i.e., each Zone has one Space. Pollination seems to regard Room = Zone = Space.
However, one Zone can have multiple Spaces in EnergyPlus, which allows users to assign different Occupancy, Lighting and Equipment loads in one Zone.
We do not yet have a way to distinguish between EnergyPlus Zone and Space but it is on our roadmap and you can expect us to have support for it within the next few months. For now, each Pollination/Honeybee Room is translated to exactly one Space and one Zone.
By searching this forum, you can see that we have had several long discussions about the best way to do this. Now that I have realized that almost everyone who wants this feature is primarily interested in it to make their large EnergyPlus models simulate faster, I think I will implement this in a manner that allows you to group Rooms to be in the same OpenStudio/EnergyPlus Thermal zone. And we will leave the logic of one Rooms to one Space.
The ability to assign a Zone to Pollination/Honeybee Rooms will be completely optional and, in the event that it is not assigned, we will fall back on the current behavior of mapping each Room to one Zone. If you have any other thoughts on this implementation or key workflows you want to be sure we support, please let us know.
@chriswmackey Thank you for your reply. I look forward to the feature update.
I see. This is the case when users convert a Revit model to an energy model.
It is not a very important/urgent feature when we create energy models from scratch as we can draw a Room so that it includes some spaces with the same space type classification and the same HVAC system.
This is great to hear - FWIW, having ‘Spaces’ nested inside ‘Rooms’ would be super helpful for our use-cases.
In case it is at all helpful or relevant to your work on this:
In our specific situation, we are required by our model-reviewers to report out detailed room-level information for each named/numbered space in all cases - and so we very much like to keep track of that information in the HB-Model.
To that end, in the Honeybee-PH plugin we implemented our own “Space” entity, which is hosted on the HB “Room”. These spaces have their own geometry, (floor-area, volume) and their own attributes such as name, number, and some program information such as ventilation flow-rates. These are the key items that we’d love to see at the “Space” level in any official HB implementation.
In our case, we have a ‘Space’, which in turn can then have one or more ‘Volumes’ (ie: a bedroom with a closet is one “Space” but has two areas, physically separated). Each Volume has one or more “Floor-Segments” which describe the physical shape of the space.
Much of that may be specific to our use-case, but I thought I’d add it here in case it is relevant.
It’s good to know about how you’re currently tying to solve the PH use cases but a native honeybee implementation which tries to subdivide Rooms into spaces would break too many existing capabilities to be worthwhile and it would not really address the situations that others have brought up here. Plus, it doesn’t really align with how most people are creating CAD/BIM models these days where Rooms (by default) are bounded by physical walls/roofs/floors and, if things need to be subdivided further, people use room separation lines (aka. AirBoundaries) to split the Rooms further.
So, while I can definitely tweak things about the planned implementation, I’m confident that Zone should be something that applies to several Rooms instead of trying to add some way to break Rooms down further.
What you are describing is a situation where maybe you have a large indoor area and you want to break it down into a few Rooms with AirBoundaries in between them. Then, you can treat each Room as what you are calling a “Space”. And, when we finish the new implementation, you’ll have the option of saying all of the Rooms are part of the same Zone (served by one set of HVAC equipment) or they are each separate Zones.
Could this still work with your honeybee-ph implementation? Or is there something about the way that we let you group Rooms into Zones that would help you make use of it on your end?
That makes sense - keeping the Room as the smallest unit, and then building up from there seems like it could work just fine. I should have read the other thread more closely to better understand - that makes sense though.
But yes: I think having a ‘Zone’ which encompassed several “Rooms” could pretty easily be re-worked into the HBPH model without much of an issue. So long as the new “Zone” entity has the same plugin extensibility and .properties as the rest of the model objects - I am sure we could utilize it without any issue.
For HBPH we added both a “Space” (a segment of a room) as well as a “Building Segment” which is something of a “Zone” but more for us to define tower vs podium, “east” wing vs “west wing”, etc… and define some ‘segment’ scale attributes. Which is all just to say that yes: having the ability to group or manage elements at multiple scales is super useful and something we’d love to see included in the core honeybee libraries.
I’m glad that you think a strategy could work that maps Rooms to Space with a Zone being made up of several Rooms.
However, I can see that the implementation that we have in mind is a little different from what you were thinking since we were thinking that Honeybee Room.zone should be implemented very similarly to how Room.story is implemented. You can see here in honeybee-schema and here in the honeybee-core Room docs that Room.story is just the id/name of the story on which the Room is a part of. It is not an object with its own properties and therefore would not have .properties that could be extended.
I realize that this runs a little bit counter to how most other BEM interfaces have implemented Stories and Zones, which tend to be full objects with their own properties and Spaces nested underneath them. It’s not that I think this approach is wrong but it really limits your ability to use the schema to construct/deconstruct/edit models. You are essentially forced to have a full zoning setup in mind when you start model-building so that you first lay out your Zones and Stories on which to put your Rooms/Spaces. This also makes it tougher to do things like delete/add a Room from the Model or change a Room from one Zone to another.
You’re essentially forced to walk though the whole hierarchy every time that you want to make a change. So the schema becomes more of a “full building energy documentation” tool to be used after you have already finished the design process rather than a “building energy creation/translation/experimentation” tool that you use throughout design.
If the zone is only the text property assigned to a Room, it becomes very easy if you want to change the zone that a Room is apart of (just change the text). It’s also easy to edit the model geometry this way since deleting all of the Rooms in a Zone automatically deletes that Zone without the need to delete some other object in the hierarchy. And, because we can always fall back on the idea that one Room gets a single Zone with the name of the Room whenever a Room.zone is not assigned, this enables people to build new model geometry without having to know the zoning layout first.
If all of those arguments aren’t enough of a reason, I may invoke the “flat is better than nested” axiom of the Zen of Python. It’s not that nesting things never has a purpose but, if you have an opportunity to avoid nesting, it will usually pay off to keep things flat.
I’ll try to think more about whether there is some elegant way that we might be able to give you something similar to Zone .properties. We will be developing a set of rules to resolve things like what happens when two Rooms have different Setpoints (probably the more stringent ones will govern the full Zone). Maybe the methods that we implement to resolve this will give you something that you can use on your end.
ah - I see, that makes sense - and yes I was assuming that the ‘Zone’ would be a sort of parent object.
It doesn’t sound like these new zones will really map onto the ‘Spaces’ or ‘Segments’ organization that we’ve implemented in HBPH after all - but that is fine - no need to make any significant changes to HB Schema or this new zone implementation since we already have a method that works well enough for our purposes.
