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).
The component is working as intended but I think you might not be understanding how Story multipliers work and how to get rid of them if you are committed to modeling everything as explicit geometry.
When you use the Story multipliers, the geometry for the Story is modeled only once on the bottom-most floor and the results are simply multiplied by the factor. In a lot of cases, this reduces urban simulation time from something like an hour to a few minutes. But, if you go this route, you are accepting that the results are going to be a little bit different from the most detailed simulation you can run. And part of this is that, whatever boundary conditions are set on that single bottom-most floor are what get multiplied by the factor. That is what is happening in your screenshots.
If you are committing to modeling everything explicitly without multipliers, then you can DF Deconstruct All on your Building and rebuild it from the individual Stories. This will have all of the Building modeled with explicit geometry and here is a sample:
Note that, for the first Building, you are plugging in only a single Story with a multiplier of 4 on it while, for the second re-built Building, you are passing 4 explicit Story geometries, each with a multiplier of 1.
This gives you the result that you were expecting:
What I meant is that, if I am not mistaken, in the case you are showing, we should get something like the following image, as there is no adiabatic condition for this specific facade on the second floor:
Is it possible that the adiabatic condition of party walls is calculated based on the overall outline of the adjacent building rather than its more detailed geometry?
It seems to me that it is accounting for the overall building outline projection up to the last floor, as shown in the left image below (“adding” the geometry painted in purple), and not taking into account the “real” detailed geometry as in the right image:
Thanks for clarifying, @jordibrunet , and I’m sorry that I didn’t read your original post more carefully.
You are correct that the routine of the “DF Process Alleyways” component was only checking the footprints and overall building height of the two buildings in order to determine whether a given wall of a story should be set to adiabatic. My original thought process was that people typically use this component on large urban areas and so the speed of performing the intersection check with only the footprint might be desired over the accuracy of getting every single wall boundary condition set correctly. After all, there can easily be cases where the floors between two neighboring buildings are misaligned and so we’d already be accepting a little inaccuracy in this case.
But I can see that the component really should be able to set the boundary conditions correctly if the input that you supply really is clean enough. And, honestly, this does not increase the runtime for large urban areas all that much because I always perform a boundary-rectangle check between any two buildings before I start doing the more computationally-intensive intersection checks. So I made a change to the source code such that the “DF Process Alleyways” component will now check each unique story of each building for overlap before setting the adiabatic boundary condition:
This gets your case to show up as expected if you don’t use any multipliers on either building:
