gbXML generation problems - using Honeybee and GrizzlyBear

Hi Mostapha, Chien Si and all,

Firstly, I would like to thank Mostapha for your reply and your kind help!

In order to link GH and DesignBuilder, I have being trying to generate the gbXML format from GH models using Honeybee and GrizzlyBear via some simplified building geometries (like indoor stadium and simple boxes), but I encountered some problems showed in the following images.

Could you please let me know how I can solve these problems? I have attached the rhino and gh files I’m using and also left my questions in the files.

Thank you all in advance!



GrizzlyBear test.3dm (259 KB)
GrizzlyBear (187 KB)

Hi Mostapha,

When I change the unit of my rhino model from Millimeter to Meter, I got the correct adjacent surfaces from " Solve adjacencies " component. Is that because of something related to “tolerance” as I saw this within the code - def shootIt(rayList, geometry, tol = 0.01, bounce =1)

However, GrizzlyBear still reported the following error message:

  1. Solution exception:MakeBuilding() takes exactly 3 arguments (1 given)

Did I miss anything? Any help is much appreciated!


Hi Ding,

I’m modifying solve adjacency component ( I answered to your questions inside the file. It exports gbXML file.

If you have a github account I suggest you to send the issues to github as these components are still under development, otherwise it is fine to send them here.


GrizzlyBeartest_msr.3dm (228 KB) (201 KB)

Hi Ding-

I also wanted to say that the epd, lpd, and Bldg Type currently are not hooked up in Grizzly Bear. These are placeholders that are confusing and we’ll delete these until they are ready.

Sorry for any confusion that this might have caused you.

Best of luck,

Dear Mostapha and Chien Si,

Thank you so much for your kind help and your great tools!

Based on the model you sent back to me, I have further tested the possibility of interoperability between HB, GB and DesignBuilder (DB).

GB does export the gbXML file and geometrically works fine with DB. But, the schedule, load and construction information (which I assigned in HB) lost when imported in DesignBuilder, and some information like building area of each zone showed in the exported gbXML file didn’t match with the actual building area in the GH model.

I also found some tricky problems when I used some of the updated HB components, so I left my questions in the gh file and look forward to hearing your suggestions. I have attached the gbXML file generated by GB and hope it helps.

Thank you again for your kindness!




Q7 (figure 1)-Failed to find SuperMarket Infil Half OnQ8 (figure 2)-Area did not match with the GH model

GrizzlyBeartest_msr_dy2.3dm (280 KB) (232 KB)
test20140625.xml (530 KB)

Hi Ding,

Thank you for trying GB and letting us know. I will check the gh file for your questions soon but before that back to gbXML import are you sure if DesignBuilder is capable of importing schedules? As far as I can see it is an option for just importing the geometry:(


Hi Mostapha,

Thank you very much for checking the files for my questions.

Regarding the capability of DesignBuilder for importing and exporting, you can see the file formats which DB allows to import and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about “import geometric data”.

However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and “Template” (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). “Templates” are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).

Both "Component " and “Template” are allowed to be imported and exported by using “Import / Export library data” command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).

In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:

  1. GH(HB+GB) --> gbXML (both geometric and "Component " and “Template” information) --> DB

This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.


  1. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and “Template” information only) --> DB

If the first way doesn’t work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.

I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?

In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?

Thank you again for all your help!



DB import

DB export

Template libraries

Component libraries

DesignBuilder help file:…

Hi Ding,

Thank you for the informative reply.

Please find the answer to your questions in the attached file. For some of them I need more time. Again your questions are best suited for github. It should be easier to track the questions as separate issues. It can easily get lost inside a gh file.

The issues with importing schedules and loads are shortcomings of DesignBuilder importer. Honeybee assigns and exports them. Let’s wait for a reply from DesignBuilder team.

I don’t suggest you to customize gbXML file as it is an standard format and it should stay the same between different programs.

Nevertheless what is the advantage of DesignBuilder for your project? Is it possible to use OpenStudio instead of DB?

Mostapha (226 KB)

Hi Mostapha,

Sorry for my late reply and thank you very much for your kind suggestions!

The reason why we chose DB is that it can not only conduct energy simulation by running Energyplus but also carry out the reliable CFD simulation and assign the CFD boundary condition from the Energyplus simulation result easily. For our case, the “temperature distribution” is quite important due to its large volume of the building (because different locations within the large volume/thermal zone have quite different temperatures)

Is there a way, do you think, to figure out the “temperature distribution” within a large volume/thermal zone by using OpenStudio?

If we cannot get the “temperature distribution” directly from the CFD simulation (because it is time consuming and not suitable for the early phase design), we supposed another compromised way - dividing the large volume/thermal zone into small thermal zones separated by zone boundary surfaces that don’t really exist - like “air walls” material (in Energyplus/OpenStudio) or “virtual partitions” (in DB).

l “air walls” in Energyplus:…

l “air walls” in OpenStudio:(using Energyplus as its simulation engine)…

But if I understand right, according to the OpenStudio Developer, “air walls” in OpenStudio are in support of Radiance simulations instead of energy simulations.

l “virtual partitions” in DB: (using Energyplus as its simulation engine)…

A virtual partition is a partition between 2 zones which exists purely to sub-divide the space up and has no corresponding wall in the actual building. Virtual partitions are modelled using a “hole” that fills the whole surface area.

The way that airflow through holes (and virtual partitions) is modelled depends on the Natural ventilation model option selection, including “scheduled” and “calculated” natural ventilation. In the Scheduled Natural Ventilation, the airflow through internal holes is calculated (using the EnergyPlus Mixing option) based on the airflow rates and schedules for this flow; In the Calculated Natural Ventilation, the airflow through holes is calculated (using the EnergyPlus Airflow network) based on the pressure difference across the opening and a coefficient of discharge of 0.65.

However, I was wondering if the gbXML file generated from Honeybee Zones and GrizzlyBear includes(defines) the information regarding these “holes” or “virtual partitions”? In other words, is it possible to automatically generated “holes” or “virtual partitions” (which allow airflow between thermal zones) in DB when importing the gbXML file (generated by Honeybee Zones and GrizzlyBear)?

Alternatively, can we just use Energyplus related components in Honeybee to get each different temperature of the subdivided thermal zones which compose the large thermal zone and allow airflow between them? How to achieve this? (Share surfaces between the subdivided thermal zones should be carefully treated to approximate the situation of airflow through “holes”)

Thank you again for all your help!



hi Ding-

What you are asking for is three different things:

1.) That Honeybee will recognize a hole cut in a surface in Grasshopper as an air wall. It should be possible to cut the hole in the wall, but currently, the wall does not get turned automatically into an air wall. This however, is likely not the only root of the problem.

2.) You can manually assign a wall to be anything you want in Honeybee, including an air wall, though this was not the purpose of the latest release of Honeybee, it is possible.

3.) Even if the assignment is there, will DB recognize it? You can check this if you want by changing an interior wall to “air wall”. Will you test if when you have done this, if DB recognizes it or not?

You may or may not be surprised to learn that nearly every import tool ignores the surface constructions. I encourage you to try and raise this as an important issue with DB. When enough people complain loudly enough, it seems to get pushed up the cue. This is not an attack on DB, it seems to be the way I’ve seen most software development make progress.