Multiple floors modeling in HB

Hi @chris,
Do you mind checking the attached file?
After you comments in this topic, I’m try to model a multiple floor building in HB.
I have a couple of questions:

  1. If the way i’m duplicating floors is what it is supposed to be? Couldn’t find a better one (See red “circle”)…
  2. Didn’t understand the functionality of the multiplier and SetStory components (see question sign).

-A. (93.2 KB)

I’ll take a look after doing the official release in a couple hours.

Hey @AbrahamYezioro ,

To second what Mostapha said earlier, we’re always impressed by how quickly you can integrate a component we literally added 2 days ago into your workflows. If only there were a discourse badge for “first line of defense against bugs” you would have earned it several times by this point. :slightly_smiling_face:

Your file is definitely a correct way to set up an energy model but I also realize that you are asking for a bit of a visual scripting style guide for these cases. Or, to put it in the terms of the Zen of Python, you’re asking when is the Honeybee workflow that I described in the other topic “the one (and preferably only one) obvious way to do it.”

If I were modeling the case in the file you uploaded, I would have to say that Dragonfly is still probably the most elegant and “the one obvious way” to build a model like that. This way, you just set up one of the stories once using 3 Room2Ds and you account for the other repeating stories using Dragonfly Story multipliers. This means that you don’t need all of the native Grasshopper components that duplicate the geometry and you have the option when you export from Dragonfly to either get detailed representations of the repeating stories or just multipliers for a faster simulation.

So, to better illustrate the point I was making in the topic you referenced, I put together a sample that has repeating stories (like Dragonfly) but it does not abide but the extruded-floor-plate logic and therefore requires Honeybee in order to be built. And we will say for the sake of argument that I want to model heat flow between the upper and lower stories such that Dragonfly’s assumption about fully adiabatic floors and ceilings won’t cut it. So, I pulled 2 zones that are part of repeating apartments in my thesis project, which had sloped south-facing greenhouse zones that repeat from one story to the next. (76.5 KB)

Here’s a visual of what the boundary conditions should look like (Pink is adiabatic for the surfaces adjacent to interior zones that I’m not modeling and green is a surface boundary condition):

… and I want to have each of the 2 zones that together make up the apartment have the same story like so:

The file shows you that I can just define zones of one apartment once (with all of the detail about how each of the spaces are used and which adjacencies within the apartment are air boundaries) and then I just move/copy them (with all of their properties) to build up a single model with repeating stories. Then, I solve adjacency between all of them and I have a model that’s effectively like a Dragonfly model in that it’s organized neatly into repeated stories but has the added benefit that the geometry does not need to be extruded floor plates and that I could also solve adjacency between floors (if I intersected the interior surfaces correctly).

You’ll also see that, if I wanted to replicate Dragonfly’s use of multipliers to represent repeating stories in order to have a faster simulation, this is as simple as just connecting the zones to the multiplier component. Then, when I go to simulate them, the results for that zone will just be multiplied by that factor.

Hope this clarifies the points that I was making and when it’s helpful to use Honeybee to build larger models.

1 Like

This is great @chris. Thanks.
I understand when (and why) one track can be more effective than the other. The pre-fabricated against the tailored … :slight_smile:
The example really helps to understand what i was asking regarding the multiplier and stories. As a matter of fact i thing they can save the array i was using in my file.
As for the

You know that i enjoy doing it besides that i’m strong LB believer, which also helps to encourage myself.

Thanks again,

Too soon … maybe.
Please see the attached file: (138.3 KB)
Check the top solution. I’m trying to copy and rotate ech floor in relation to the previous one. It is working nicely.
The issue is with the adjacencies between floors. I was expecting that part of the floors will be exterior and part interior. They are only when the rotation angle is 0. Bigger than that they are all exterior.
Am i doing something wrong or there is a bug or … something else?

And another question regarding the multipliers. Is there a way to check visually the “presence” of the multiplied stories as in DF?

Am i pulling the robe too much?

Hi @AbrahamYezioro. If I may, I checked your definition. The possible reason for the part of the floor is not distinguished as exterior and interior are that, after adding multiple floors it has to be passed through intersecting solid component to create matchable surfaces. Then pass the data through solve adjacency to get as desired boundary condition. I have attached the modified file for reference. But still, @Chris can provide an accurate method to perform this. (147.9 KB)

Thanks @Asisnath,
Interesting approach. Two things about it:

  1. Probably creating the whole geometry BEFORE start using any HB component can be better. Even though your solution seems to work, but i don’t like it very much, since you redefine the rooms again and you loose the names.
  2. There is no intersection between the geometries. They just touch each other. Moreover, when the rotation angle is 0 my version works ok. I think something in the algorithm of the SolveAdj component is not working well for floors. Otherwise i don’t see why in walls it works as expected.
    Let’s wait for @chris’s opinion.

Hey @AbrahamYezioro and @Asisnath ,

You found the chink in the armor. Surface-to-Surface intersection for is currently the only geometric operation that needs to regularly be performed on Honeybee geometry that does not exist in ladybug_geometry. That makes it the only thing that’s stopping us from enabling the more elegant way of copying all objects and then always being able to seamlessly intersect + solve adjacencies between all of them. I know that the solid intersection can definitely be implemented since there are open source libraries that do it like the Boot Geometry library that OpenStudio uses. Or, if it really comes to it, I could write something that just does the intersection part with Rhino and does the management of everything else in Honeybee (I think this is what I’ll do if I don’t have surface intersections in ladybug_geometry by the next stable release). But I know that being able to intersect two honeybee rooms and have them maintain all of their properties after the intersection would be a huge help in making scripts like this much more elegant. You can see that we figured out the intersection of matching Room2D polygon segments in Dragonfly and it makes the process of building Dragonfly models MUCH more elegant. So just know that it’s coming an, in the meantime, I can offer you 3 ways to work around it:

  1. Use @Asisnath 's strategy of duplicating all geometry and doing intersection before the creation of honeybee rooms. If you set things up this way, there will be a bit more work if you want to convert them over to the new workflow when it’s ready. It also makes it harder set properties of the repeating set of rooms since you have to set multiple versions of the repeating rooms with the same properties. But this is always a valid way to do it.

  2. If you are using the same geometric transformation from story-to-story, you can set up your initial rooms so that they are already intersected. For example, if you are always moving and rotating your rooms by the same distance and angle between stories, you can split the floor and ceiling surfaces of the first set of rooms so they are all ready to be adjacency-solved after duplication. This is what I did in the sample I uploaded earlier and you can see that I provided a sample of it for your case in the attached file.

  1. Just take “the Dragonfly philosophy” and treat all ceilings and floors as adiabatic. While this compromises a bit of the accuracy since you might miss some heat flow through roofs and floors, this might be the best for now as it can be easily converted over to the new workflows and you don’t have to do any custom splitting of the geometry beforehand. You can see an example of this in the attached file. (190.4 KB)

1 Like

Also you can always check the multiplier on Honeybee Rooms like so:

You made it clear. @Chris I was expecting an answer something as you mentioned above.

Thanks @chris,
Very clear explanation what and why happened. Looking forward, already, for the next stable version … :slight_smile:
Agree with you that probably option 3 is the one to follow right now. In any case this is just a test file while checking capabilities and workflows. Didn’t expect to find the “chink in the armor”.
BTW i created the option 1 and is not that complicated to set the properties. But is definitively not a path i want to follow.

Yes. I’ve found this option before. But still i was looking for a visual show of the floors, as in DF you have one.
Thanks @chris,

Ah, I see. My answer to the multiplier question in Honeybee really hasn’t changed from what I posted here:

It’s just hard to do this elegantly when there’s no hard-and fast rule in Honeybee that multipliers need to refer to repeating stories as they do in Dragonfly (eg. they might be repeated horizontally). And, as we see from some of the examples here, the ceilings of Honeybee Rooms don’t need to be flat so simply offsetting them vertically by the z dimension of the Room bounding box might not produce desired results.

Maybe I could make something where you can optionally plug in a vector to specify the direction (and distance) over which the Rooms repeat. But, before I do this, what about a solution that uses native Grasshopper components like this?

This is perfect @chris!!

Hi @chris,

I’m also trying to model multiple floors, and I’m having issues with it.
I didn’t start a new topic, I thought it could fit here.

I have my rooms modeled in Rhino as solid boxes (apart from one polysurface underground) that I referenced one by one, used the HB Room From Solid component a few times, assigned the levels so far and I ran the Solve Adjacencies component then visualized the model by Type and by BC to check what I have so far.

I realized I don’t have a continous thermal envelope in the model and the roofs/interior floors are also mismatched.

I’m not sure what I am doing wrong, I went through the Vimeo tutorials but I have only a vague understanding what is going on with a model this complex.

Could you take a look, what is the issue here?

I internalized all the inputs and marked the components in question.

LB_forum_bc and type not set (223.0 KB)

I simply didn’t use the Intersect Solids component beforehand and a lot of surfaces weren’t matching. :clown_face:
I needed to setup the model again to have the script work, then I was able to export to OpenStudio…

Hi @chris,
I’m bring this one alive again after a long time.
Just wonder if the new LB geometry libraries enable a better SolveAdjacencies for floors (internal/external).
The reason i’m rising this again is because i have a case where the floors are repeating rotating by some amount (equal or different).
Using option 3 above (Dragonfly philosophy (set ceilings and floors as adiabatic) has the mentioned limitation BUT it allows me to have the same window ratio for the same rotated facades.
Using option 1 (doing all transformations before HB actions) allows to ave the correct internal/external ceilings/floors but assigns window ratios according to the actual orientation (as opposed to the previous one).
The attached file shows both options.
From what i understand with the Pollination developments, probably this geometrical issue is solved and can be probably implemented in the SolveAdjacencies.
Too much to hope?

-A. (104.0 KB)

Hey @AbrahamYezioro ,

You would be correct to point out that the Pollination Rhino plugin makes the process of solving adjacency for cases like this very easy. However, this is because the Rhino plugin keeps a coordinated copy of both Rhino geometry and Honeybee Model geometry so that we have access to all of Rhino’s powerful intersection functions directly with the Honeybee model geometry. In Grasshopper, once you create the honeybee objects, you really only have ability to edit the geometry using the Ladybug Tools SDK, which has almost all geometry operations that you might want to perform (eg. windows by ratio, move, rotate, etc.). However, the core ladybug-geometry library still lacks the powerful intersection functions needed to get the adjacent areas matching correctly. We’ll get to this eventually but it’s not currently the highest priority because the Pollination Rhino plugin does this type of thing vey well.

If you really need a script like yours right now that does not rely on the Rhino plugin, I recommend rotating the Honeybee geometries to get the ratios you want like so: (100.3 KB)


Hi @chris,
You are sneaky … :wink:
There is nothing like to look out of the box. Nice solution.
EDIT: I kept thinking about this. It is true that the Rhino plugin solves cases like this easily. BUT … for cases where you want to parametricaly model and simulate, then the Rhino option is less useful (unless there is something in the workflow that i’m not understanding properly).
Makes sense?

Yea, that’s why we’ll eventually get around to adding intersections into the LBT SDK. Some parametric models are set up in a way that I can be sneaky like the sample above but it will be nice to eventually have something that can easily work for all cases.