Create a zone with multiple spaces and how to organize them

Hello everybody!

I feel like i’m going back to the basics, but I have a fundemental question.

How do you create different spaces under a same zone?

I normally model with breps, one block per space, but the project requirements and the HVAC system that my office has designed for x building requires me to set zones, along with spaces. (Naturally has to do with different internal gains, etc and the way the thermostats are positioned)

I have tried a combination of ways with the join breps (but that removes intermediate floors, and therefore the floor area), solve adjacency… HB SetZone…

Does any body know how to properly manage space/zones?

Thank you so much.

I’ve seen the last post similar to this question is from 2018 and i couldn’t solve it from there.

Hi @adrisonet

I am pretty sure that the actual Honeybee model is ‘flat’ in the sense that there is really only the Room which maps to the EnergyPlus Zone.

There * is * the new zone attribute, but as far as I am aware this is just a sort of internal ‘classifier’ which you can use to sort and organize rooms (similar to story) - not anything that maps to an EnergyPlus object.

Which is just to say: I think you can only make Rooms (which are E+ Zones) in Honeybee.

Some relevant posts about this include:


So in practice, we have to build all the Rooms for the building first by mechanical equipment (zone), and then split up each of those blocks up based on internal loads (program).

I’d certainly be curious to know if I’m wrong about that though?

best,
@edpmay

1 Like

Hey @adrisonet ,

Your question is incredibly timely. @edpmay has correctly described how honeybee has historically worked and he has done some great work for me in gathering old posts that I need to update (thank you, @edpmay !)

I say this because we just finished adding full support for zones to the development version of Ladybug Tools last month. To make use of the new capability, you can use the new “HB Set Zone” component to assign a zone name to rooms. Once this is done, this will cause energy simulation results to be reported for the zone rather than the rooms like so:

This also means that both Honeybee Rooms simulate with the same thermostat in EnergyPlus (and use an assumption that the air is at the same well mixed temperature between the rooms). So each of the two rooms map to separate EnergyPlus Spaces and the two rooms together map to one EnergyPlus Zone.

You can get the new “Set Zone” component by using the latest Pollination Grasshopper installer or the LB Versioner component. It will also be in the LBT 1.9 release that should be happening in the next week or two.

2 Likes

nice! This is great to hear.

I’ll experiment, but can I ask: does this change the actual model structure itself (ie: is there a new ‘zone’ object?), or is this an attribute of ‘room’ which then does some behind-the-scenes magic when exported to OSM to create the zones?

@edpmay

It is the latter. I ended up implementing it the way that I described in this part of that post that you linked to:

So there is no zone object in honeybee or dragonfly schema and all of the “zone attributes” like setpoints and ventilation are still assigned on the room/space level. The decision came down to whether I wanted to make the lives of the users easier, letting them easily change zoning by just changing a zone name and assigning setpoints with all of the other criteria about how the spaces are used in ProgtamType. OR did I want to make my life as a software developer easier and avoid having to implement “magic” to resolve cases of two spaces in the same zone having different setpoints. I chose to go in favor of making the users’ lives easier.

If you want to access the “magic” by which zones are resolved for your honeybee-ph purposes, pretty much all of it can be obtained through this method I added:

… and you’ll see that the docstring describes how cases like conflicting setpoints are resolved. This is the list of all changes that happen before the zones are translated to E+:

  1. All Zone names in the model will have non-ASCII characters removed so that are accepted by EnergyPlus.

  2. If not all Rooms of a zone have the same thermostat setpoint, these will be edited such that the strictest setpoint of the rooms at each timestep governs the thermostat setpoint of the whole zone. That is, the lowest cooling setpoint always governs and the highest heating setpoint always governs. So all Rooms in each zone will have their setpoint property re-assigned.

  3. If not all Rooms of a zone have the same ventilation requirements, these will be edited such that the ventilation requirement of the zone is equal to the sum of the individual room ventilation requirements. Total outdoor flow rates are summed across the Rooms, flow-per-floor area gets recomputed using the floor area of each Room, ACH flow rates get recomputed using the volume of each Room, and the flow-per-person is set to the highest value of the Rooms in the zone. If all Rooms have ventilation schedules, then these are recomputed such that the highest value governs at each timestep.

  4. If not all of the Rooms of the zone have the same multiplier, then the highest multiplier of the rooms in the zone sets the multiplier of the zone.

  5. If not all Rooms of the zone have the same exclude_floor_area value, then the rooms with excluded floor area will be pulled out into separate zones from the ones that have included floor area, which will retain the original zone name.

I know the decision makes your job as a software developer a little more complicated, @edpmay but hopefully that resolve_zones method in honeybee-energy helps keep your code clean and simpler.

Very cool. This makes sense. We have a very similar function in our PH-Exchange library since all of the Passive House models only accept a ‘single-zone’ model:

I am sure the new zone attribute will be plenty useful in managing large models though.
-e

1 Like