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.
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?
Thankās @chris.
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 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:
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.
