Is there a solution to resolve adjacency / boundary condition for abutting buildings in Dragonfly?
Attached are screenshots of an example block of 7 buildings, typical in the city I am working on. When I remove visualization of the roof, you see windows located on the abutting walls between buildings.
Also the boundary condition for the abutting walls is ‘outdoors’ - I suppose it should be adiabatic, at least when below the roof line of the adjacent building - is that correct?
I’m attaching my GH script where I’ve tried two workflows - one from footprint to DF buildings, and a second which attempts to then decompose the solids to use the DF intersect & solve adjacency tools. But in both cases I have the same result.
If you input a series of room as a tree into the solve adjancies it will only look at the adjancies into the different lists, so if you flatten the tree of rooms it will do the solve adjencies correctly. Also there are some inaccuracies in your building footprints.
Thanks very much for your response. Your solution is elegant and indeed works very well for the simplified block example I posted.
For the larger model I’m working on, however, I couldn’t get this solution to work.
My case study has hundreds of buildings, see below:
The geometries come from the city GIS model - I believe taken by Lidar, so they should reflect real-world conditions.
As you suggested, I tried flattening the input before entering the IntRoom2D tool and then re-grafting after adding HVAC, but I end up with adjacency warnings (see below). The buildings with errors also seem to have both ‘outdoor’ and ‘other’ as boundary conditions:
I attach a simplified version of my GH script with a sample of just a few of the buildings. My model is split into archetypes (there are dozens of them in the case study) so that I can apply separate construction sets, schedules/programs, and HVAC equipment for each. This simplified script has 5 buildings for 6 of the archetypes - some of which are abutting and others are not, and some of which have adjacency issues and others do not.
@chris - you had mentioned a potential tool to assign adiabatic boundary conditions by proximity, in order to resolve abutting buildings. Do you think there is a way to resolve the adjacency/boundary conditions here using Erik’s suggestion, or should I wait for the tool to become available?
Thanks for posting and sorry for the late response here. @Erikbeeren 's response was a good one for the simple case that you posted since a block like that really looks like it could be a single courtyard building.
But I recognize that there are many more cases in urban areas where you have really narrow alleys between building geometries, which do not form a continuous courtyard shape. So you just want to remove the windows from the alleys on any wall that’s within a certain distance of other buildings. This is fairly straightforward to do with the Dragonfly SDK if you know your way around and I’ll try to post a sample here before the end of today.
Enough people have asked me about this specific case that I may just add an official component for it. Let me see how it pans out.
I have a working sample component on my end but I realized that the code to implement it required some deeper knowledge of the Dragonfly SDK than I expected (at least if you wanted the calculation to run efficiently for large numbers of buildings). So I’m going to add a dedicated method in the Dragonfly core SDK for this and I’ll also add a new Grasshopper component to the Dragonfly plugin. Let me see if I can get it all implemented by the end of today so I can give you something official. Otherwise, I’ll upload the sample component if I don’t get it done in time. Here’s a screenshot to prove that it’s working as intended:
I have merged the new component into the official LBT plugin and you can get it on your end by running the LB Versioner component. Once you do this, you will be able to open this updated version of your initial script, which produced the model that you see in the last screenshot that I posted:
This is what the new component looks like and you can see that it has inputs to adjust the distance between buildings at which you want to remove windows and the option of making the walls adiabatic or not, which enables the component to be used for alleys as well as parti walls:
I had exactly the same problem. I tried to update version but failed.
The LB Versioner component turned to red and said:
Runtime error (PythonException): Download failed with the error:
<urlopen error [Errno 10013] 以一种访问权限不允许的方式做了一个访问套接字的尝试。 20.205.243.166:443>
Traceback:
line 218, in _download_py2, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\futil.py”
line 279, in download_file_by_name, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug\futil.py”
line 153, in latest_github_version, “C:\Program Files\ladybug_tools\python\Lib\site-packages\ladybug_rhino\versioning\change.py”
line 90, in script
Can I manual update the version? Where can I download it?
A nice aspect is that I can run the tool once just before sending the buildings to create the DF model, as I begin with separate/parallel streams of DF buildings (for different building archetypes i.e. construction sets, programs, etc.) and then just solve adjacencies at the last step.
Glad that it’s working well for you, @anthony . It’s looking good!
@Fiona , it looks like there’s possibly some security setting that’s preventing you from using the LB Versioner. I think the new component is in the latest Pollination Grasshopper single-click installer if you want to install it that way, which should get around any security issues.
