gbXML generation problems - using Honeybee and GrizzlyBear

Replies to This Discussion

Permalink Reply by Ding on June 21, 2014 at 8:48am

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!

 

Ding

Permalink Reply by Mostapha Sadeghipour Roudsari on June 21, 2014 at 6:23pm

Hi Ding,

I'm modifying solve adjacency component (https://github.com/mostaphaRoudsari/Honeybee/issues/75). 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.

Mostapha

Attachments:

• GrizzlyBeartest_msr.3dm, 228 KB
• GrizzlyBeartest_msr.gh, 201 KB

Permalink Reply by Chien Si Harriman on June 23, 2014 at 10:34am

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,

Permalink Reply by Ding on June 25, 2014 at 5:04am

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!

 

Best,

Ding

Q1

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

Attachments:

• GrizzlyBeartest_msr_dy2.3dm, 280 KB
• GrizzlyBeartest_msr_dy2.gh, 232 KB
• test20140625.xml, 530 KB

Permalink Reply by Mostapha Sadeghipour Roudsari on June 25, 2014 at 5:52am

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:(http://www.designbuilder.co.uk/content/view/67/106/)

Mostapha

Permalink Reply by Ding on June 27, 2014 at 10:03am

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.

(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25...)

 

2. 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!

 

Best,

Ding

DB import

DB export

Template libraries

Component libraries

Permalink Reply by Ding on June 27, 2014 at 10:07am

DesignBuilder help file:

http://www.designbuilder.co.il/files/Documents/DesignBuilderManual_...

Permalink Reply by Mostapha Sadeghipour Roudsari on June 29, 2014 at 10:58pm

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

Attachments:

• GrizzlyBeartest_msr_dy3.gh, 226 KB

Permalink Reply by Ding on July 11, 2014 at 3:13am

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:

http://energyplus.helpserve.com/knowledgebase/article/View/18/0/air...

 

l   "air walls" in OpenStudio:(using Energyplus as its simulation engine)

http://openstudio.nrel.gov/forums/openstudio-plug-google-sketchup/h...

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)

http://www.designbuilder.co.uk/helpv4.1/#Virtual_Partitions.htm?Hig...

http://www.designbuilder.co.uk/helpv4.1/#Add_Hole.htm?Highlight=holes

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!

 

Best,

Ding

Permalink Reply by Chien Si Harriman on July 14, 2014 at 10:04am

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.

Permalink Reply by Chien Si Harriman on June 30, 2014 at 9:38am

Hi Ding-

So in my experience, there are very few tools that import both geometry and schedules/constructions from gbXML.  Nearly every tool I am aware of only imports geometry.  Because of this, in the first release, we have been more concerned with exporting geometry and focusing on schedules and constructions for future releases.

There are a couple of known bugs related to schedules in grizzlybear currently, which I am in the process of correcting.

I would be surprised if DesignBuilder takes schedules and constructions from gbXML.

As for your second question.  You ask about converting gbXML to XML.  I'm not sure what format DB wants for this...gbXML is XML, so I also think we need to wait to hear back from design builder.  Currently I certainly am not intending to build a plug in specifically to import a special XML format into design builder only.

Are you still having trouble with GrizzlyBear?

Permalink Reply by Chris Mackey on July 1, 2014 at 11:32am

Hi Ding,

I know this is somewhat tangential to the main focus of this discussion but I fixed the bug in the glazing ratio component that you were experiencing.  To be honest.  I don't know why you got two different ways to break up the window for two different directions but I have put in a check that catches the situation and corrects it.  You can get the new working component by syncing with the github and you can see it working correctly in the attached file.

Attachments:

• GrizzlyBeartest_CWM.gh, 231 KB

• ‹ Previous
• 1
• 2
• Next ›
• Page