Converting HBZone surfaces from Interior Wall to Air Wall

Hey there! I was wondering if anyone’s ran into this situation as well.

I’ve been trying to intertwin masses2zones and HBZone from surfaces workflows by editing surfaces of HBZones created with masses2zones, but I found out it’s quite more complex than I anticipated. I understand it’s rather easy to modify constructions, but it applies to all of the surfaces falling into a single category related to this HBZone.

Instead, I am trying to edit a surface from a previously created HBZone from a polysurface to convert it to an air wall, which involves changing its type, and not to all of the walls in the category, but a selected few.

I am figuring there’s got to be a Data Tree Branching fiddling around involved, but I haven’t figured out how to take a branch, edit it, replace it then re run HBZone from surfaces yet.
Nonetheless, maybe there’s an option which does not involve data management of changing a surface type inside a previously created HBZone?



Just to confirm that I understand your problem: the specific issue is that you can’t figure out a way to assign two different construction types (generic interior wall construction, and air wall) to the interior surfaces of multiple HBZones?

And right now your current strategy is to create HBZones from a list of breps, solving the adjacencies to identify interior surfaces, separating the interior surfaces into two categories, and then remaking all geometries as HBSurfaces, and then rebuilding a HBZone from the new HBSurfaces - which is giving you a ‘duplicate surfaces’ error.

I can think of 4 potential workflows:

  1. The best solution is to build up your model in stages, and preserve/assign different construction types to interior surfaces through multiple Solve Adjacency components. But this depends on if you can map your logic of interior/air wall construction to the successive zone by zone construction.

  2. This solution is guaranteed to work, but isn’t scalable…Deconstruct your brep into surfaces in Rhino, and then manually assigning them to HBSurfaces. This gives you full control over setting construction types.You will probably want to split the adjacent surfaces first to ensure you can assign construction types to the correct adjacency. If you have a small one-off model (or if everything else fails), this is a good solution.

  3. The reason you are getting into the ‘duplicate surface’ error is because you are creating two HBSurfaces with the same geometry, which I believe is still being cached in Honeybee. You should be able to avoid this issue by splitting your GH script into two scripts around this area:
    image Run the first half, internalize the geometries, then copy them over to a new GH window. Close the other GH canvas with the first script, refresh the solution, and feed the internalized geometries into your workflow that creates HBSurfaces and then HBZones. This is basically a modified version of solution 1.

  4. I haven’t tested this, but something that might work. Once you have created your initial HBZones from the list of breps, and solved for adjacencies, use the Honeybee_DecomposeHBZone component to get a list of associated HBSurfaces. Use the Honeybee_Label Zone Surfaces component to filter out interior surfaces, apply your filtering criteria, then use the Honeybee_Set EP Surface Construction to reassign construction types. If that sets the EP construction globally, then I don’t think you need to remake the HBZone from the surfaces, it should just be assigned to the HBZone. You can confirm this is true with the `Honeybee_Label Zones’ component.


Thank you so much for your time, Saeran. I’m going to try your suggestions and see how it goes. The first one was the last workaround I found, similar in a way to an existing post, but were assigning the same construction type to all of the same category surfaces.

I managed to have it working by grouping air-wall-adjacent HBZones, I suppose, but there was a catch: I could only re-solve HBZones with continuous adjacencies, In a tube-like form. Somewhat like, if there were two groups of separate air-wall adjacency relationships, They couldn’t have any surface in common as it would appear as a duplicate once I recomposed the volume before running the simulation, and crash the whole thing.

Anyway after a bit of research, I found that creating air walls can often get messy, even so in regular EnergyPlus, so I suppose that’s the reason why I haven’t seen them very often, and couldn’t find a specific worflow to it.

Thank you again, Saeran! :smile:

No problem, hopefully one of these solutions works!

Not sure I completely understand this, but it sounds like you may not be splitting your adjacent surfaces correctly before solving for adjacencies. Are you making sure that all adjacent surfaces are split, so that every interior surface is adjacent to another interior surface with the same shape? I can’t tell from your GH script if you are already using it, but there is Honeybee component to split masses that you can run before making HBZones to ensure this adjacency splitting occurs. It’s also good practice to check and split brep surfaces in Rhino since the Honeybee component will miss certain cases (due to tolerance issues, and lack of robustness in certain GH geometry operations).

And to clarify, what I meant in step 1 is to start with (for example) two separate HBZone to Solve adjacency flows. First group all your zones with interior construct types together, solve and set adjacency construction to interior constructions. Then group all your zones with an air wall type together, solve and set adjacency construction to air wall. Then merge both lists of HBZones, and insert them as an input into a third Solve Adjacency component, and select the ‘preserve existing constructions’ option.


Actually, the more I think about it, solution 1 should be all that you need. It provides enough flexibility to account for any configuration of air wall/interior wall constructions.