Hi, I am a ladybug tools-beginner user. I modeld building in designbuilder and I want to export it into ladybugs in order to add 2-axis tracking option to PV panels as this option does not exist in designbuilder, so, I ask what is the appropirate file format that can be exported from designbuilder and imported to work into Rhino/grasshopper ladybug and honeybee tools? and what is the steps to be opened? Thanks…
I would try gbXML first and see how that works.
Ok and I am waiting
I’m not sure what are you waiting for here but what I meant was to export your model from DesignBuilder as a gbXML file and import it to Ladybug Tools using the import component.
Ok Mr. Mostapha, as i am beginner, is there any any illustration or tutorial of how to import gbxml to ladybug tools? Many thanks
Ok, i can but i can not find [gb XML to Honeybee] (XMLTOHB)… could you help me??
I post two version of ladybug. You just need select one for gbxml import.
Please connect gbxml to model file ,then load it
There was a problem in file path and was solved, but now it gives me this errors in the pic.
:
It seems that your gbXML model holds several geometric issues. I’d recommend you to use one of the gbXML viewers (such as this one) to better understand what’s going on with your file. Also, try and watch this video, it gives some further explanations on the matter.
Thanks for helping me
Ok Mr Tokarzewski
it is here, in gbxml. The dsb is uploded as drive link as it has large size to be uploaded here.
model.rar (90.6 KB)
https://drive.google.com/file/d/1Nu7D0Eu6w1A_rn5qiZw0V0FmD8iH2Bux/view?usp=sharing
Hi @RadwaEzzat,
LBT says that the roof surface is not valid and its aperture/opening boundary condition should not be “Ground”. This is quite odd that the roof’s aperture has ground boundary conditions.
I removed this big opening in the DesignBuilder and exported the xml file again.
Source_minus_roofwindow.zip (112.2 KB)
Now you should be able to load this xml file into the LBT.
Remember to add this hole later in the Ladybug tools.
Does someone understand why LBT thinks srf479 and its opening has ground boundary condition?
Hm. I hate to pass the buck but I think the bigger question is why OpenStudio’s gbXML translator interprets that surface as having a Ground boundary condition. Honeybee is just using the OpenStudio gbXML Reverse Translator to get an OSM that it then translates to HBJSON. Here’s a snapshot of what the imported OSM looks like for that Surface:
So the short answer is that Honeybee interprets that Surface as having a Ground boundary condition because OpenStudio interprets that Surface as having a Ground boundary condition.
For a longer answer, we should probably ask this question on unmethours where the OpenStudio developers could probably tell us why this is the case.