Hello,
I’m using Dragonfly to build a model (for energy and solar simulations) of an urban block, with the idea of scaling the same approach to several blocks at the city level.
The urban block is made of several buildings attached to each other and I’m using the process alley component to remove the windows from the shared walls and make them adiabatic. However, by doing so, I also lose the windows and the outdoor-wall property on those buildings’ floors facing a shorter building but above it (see picture).
Is there a way to automatically detect that that wall should be classified as “outdoor” and keep window properties?
Another odd behavior is visible in the second picture where I have set a distance of 10 in the DF process alley component and I lose windows on the first four floors (as I would expect) but also on the fifth and sixth that do not have anything directly in front. I’m also surprised to get windows on the top floor then.
Yes, there is. Given the way that you set up your case, the components should have actually counted those walls as outdoors. The issue was just that the elevation of floors and the roofs of the neighboring buildings were perfectly equal to one another. I changed the source code so that they have to be different from one another within the tolerance to trigger the adiabatic-setting code:
What about the other issue regarding the windows that show up only on the top floor of the Bld.1 when setting 10m as a distance, while there are no windows on the two stories underneath despite being nothing in front?
Another situation that might be interesting to look at is visible in the lower part of the picture.
The logic here is clear (the two walls are within 10m distance so they don’t get windows and they are turned into adiabatic surfaces since the boolean toggle is set to true), however, do you think it would be interesting to have a differential threshold to set the adiabatic condition?
I try to explain it better, the adiabatic condition is good to have when the buildings touch each other (very small distances in the distance input) however for larger distances (as the 10m example) we might still want to have no windows (let’s say for privacy reasons), but the wall should be classified as outdoor. Turning the boolean toggle for _adiabatic input to false solves the problem, but it also creates the unwanted results of classifying the walls touching each other into outdoor walls.
Thanks for clarifying, @Matteo . Your last paragraph helps me understand what you’re trying to achieve and you can do so by using two “Process Alleys” components in tandem like so:
I think we are facing a similar issue while using rooms2D modeling approach based on a custom workflow using a different footprint for each story. We are using a custom geoJSON with a unique layer for each building level, using it as initial room2D and then joining them into stories, buildings and finally constructing a DF model.
The DF model is correctly simulated with URBANopt (and even 5GDHC with Modelica) but the adjacency of parti walls in some buildings, when there is a number of floors difference between neighbors, are not correctly calculated.
For instance, in a building like the following image, the two lateral walls from second floor (facing neighbour A and B) are accounted as adiabatic, but they should be outside facing walls as they aren’t in contact with the surrounding buildings. The ground floor parti walls are correctly calculated.
This is happening with all the buildings of the model in a similar situation. All floors are configured with a 3 meters height.
Otherwise, if this only building (model) is configured with floors with 6 meters height (higher than the last floor of the surrounding buildings A and B) the adiabatic and outdoor condition is correctly calculated. Or even if the neighbor building B is set to 1.5m floor-height:
We are using a Rhino 7 with a tolerance of 0.01 meters, Dragonfly 1.8 and the following configuration for adjacency of parti walls with “DF Process Alleys” component:
Maybe it’s a component’s limitation when not using clean footprints approach? We have faced the same issues using 3D solids, but when using a unique footprint for each building the behavior is correct.
Some updates: we have tested it with the same geometry as the sample “rooms_to_stories_to_building.gh” but simplifying the geometry and creating two adjacent buildings, building 1 (B1) and building 2 (B2).
