Dragonfly-UrbanOpt / Modelling buildings with variable heights (and proper BC)

Hi everyone (@chris),

I’ve begun using Dragonfly-UrbanOpt to simulate the energy consumption of a neighborhood and I faced the following problem: how to model buildings with variable heights, that is buildings with large terraces?

Indeed, the massing of the project goes to that level of detail. I don’t have the floorplans yet, but I do have the volumes.

Here’s an exemple of such a building with large terraces:

My first try was to divide that volume into 3 “buildings” (level 1 to 3, then levels 4-5 and level 6) and then apply the DF Building From Footprint component to the footprints of level 1, 4 and 6. But that did not worked because the boundary conditions were wrong (each set of stories considered as a whole building by DF).

So then I switch to the room-to-story-to-building workflow. I set each story as a Room2Ds, solve adjacencies between them and join them into a whole building.

The problem here is that I don’t get the right boundary conditions in the end. It seems that the “roof” condition is only applied on the highest horizontal surface of the building. As a result, the surface of the terraces are considered adiabatic instead of outdoors (see below):

The only solution I found is to apply the DF Set Ground Top component to the stories with terraces and them only, but it’s quite painful as I have to sort them by their name and so on…

And also: by setting each story as a Room2D, I am unable to split them between perimeter and core as I could when using the perim_offset input of the DF Building From Footprint component…

Am I missing something here? Taking terraces into account seems rather important to me and I frequently encounter massings with such level of detail.

Thank you guys for any help.

Hey @JulienFBC ,

Sorry for the late response. See this sample file here for how you can set up your Dragonfly models to have exterior roofs on in-between stories.

This tutorial video and the one that follows it are also going to be really helpful for what is going on these cases:

When you build up models from individual Room2Ds, you have to do all of your zoning beforehand. You can use this HB Straight Skeleton component to do the automatic core/perimeter zoning before you go and make all of your Dragonfly Room2Ds.

… or you could just accept the default simplification of using adiabatic roofs for the mid-level stories. Honestly, over a whole district, you’ll probably find that it barely changes the EUI. Part of the reason why Dragonfly is set up like this is so that you can choose the level of detail with which you want to export buildings, depending on how detailed of a result you need, how fast you need the simulation to run, and how much time you have to build the model:

Hello Chris,

thanks a lot for your reply, and for pointing to the HB Straight Skeleton component. I guess I’ll run simulations with and without the proper BC to evaluate the error.

I think the issue is that when we solve adjacencies and intersect between rooms, that applies only to the walls and not to the floors. So we kind of have to project each floor onto the one below, which is doable but not very elegant.

Anyways, thanks again for your reply!

Right. Each Dragonfly story is its own simulate-able unit, which is why you’ll never have Surface boundary conditions between one Story and another unless you set up your model with matching Room2Ds between the stories and use the ciel_adjancency_ option when you use the DF Model to GeoJSON component.

I guess elegance is relative. It certainly would not be possible to have all of these streamlined workflows with story multipliers if we couldn’t treat stories as distinct simulate-able units. But, if you are just saying that performing the Room2D splitting is a little tough to do with native Grasshopper components, maybe there’s a way that we can put this splitting process together into a Dragonfly component. It’s just that intersection calculations like this are tough to do reliably and they are often plagued by tolerance issues. So this is why we currently want you to do them before you create your Room2Ds. But maybe we can make something that does this splitting correctly when your model has been set up well. Let me think about it.