Hi @chris, I have a doubt about defining geometry with Dragonfly for URBANopt simulation. As the script for the HQ geometry shows, I first defined the room2d, then the stories and finally the building. In order to distinguish the to_exposed and the ground, I exploded and associated the respective surfaces. I would like to understand if this approach is correct or is it better to set the residences geometry, where the building is defined as a single volume and I divided it into the various floors with the multipliers command. Thank’s.
Script 1.gh (660.5 KB)
I’m afraid that I don’t really understand your question and your file has too much extra stuff in it to make your question clear. Are you asking whether you should use “rooms-to-stories-to-buildings” workflow instead of the “from building solids” workflow? That all depends on what geometry you want to start from.
I guess the one thing that I can say looking at your file is that, if you are going to use the “rooms-to-stories-to-buildings” workflow, you shouldn’t really have to explode the buildings after you have created them. You should be able to do whatever edits you want on the Room2Ds or the Stories before you create the Building. Maybe if you make a script that more specifically shows your question, I can give a more helpful answer.
I’ve redefined the script and hope it’s clearer now.
My question is whether the assigned workflow for the bottom (in contact with the ground) and the top (outdoor exposed roof) is set correctly in model 1 or in model 2. I designed model 1 per floor while model 2 per box. Model 1 is the real geometry, model 2 is the simplified geometry.
Another question is: if I have a single box and I want to define the ground floor with a height of 6m and from the first floor 3m, can I?
Dragonfly geometry.gh (574.4 KB)
Thank you for cleaning up the model and I understand your question now. The top one is not correct and it’s partially my fault as the “DF Set Ground Top” component should throw an error whenever an unsupported object is connected (anything that is not a Room2D or a Story). So nothing was happening when you passed a dragonfly Building through the component. I added the error in now:
Also, it will probably help you to know that you can preview the 3D geometry of any Dragonfly model by translating it to Honeybee and then connecting it to any of the Honeybee “Visualize” components like so:
This should help you check your boundary conditions going forward.
This is exactly what I meant. It was also my lack, I found the component to attribute the different heights, “Buildind Footprint” does this. Thanks for suggesting the 3D geometry preview component, this is very useful. To preview the full 3D geometry I have to put “false” in use_multiplier (component “DF Model to Honeybee”). Really thank you @chris!
Hi @chris. I updated the components from GitHub. I downloaded dragonfly-grassopper-master, dragonfly-energy-master and dragonfly-core-master. I copied everything to the UserObjects folder. Now when I run the URBANopt simulation I have this problem:
I copied everything here:
This is because the development version of the plugin has been upgraded to work with URBANopt 0.4.1 as you can see in the compatibility matrix:
So I recommend either sticking with version 1.1.0 of the Ladybug Tools plugin for now or, if you are going to keep using the latest development version, just be prepared to keep upgrading your versions of OpenStudio and URBANopt over the next month or so.
Thank you so much @chris for your valuable work!