Honeybee and Openstudio dll problem


I added an Export to Openstudio component on my canvas. I got an error telling me to download the Csharp library from here: https://app.box.com/s/y2sx16k98g1lfd3r47zi

First, if I may make a suggestion:

  1. I would add these steps to the installation instructions

  2. I would double quote the path, I got confused by whether I should include the "" at the end of the path (%appdata%\Ladybug\OpenStudio).

Anyway, I downloaded the libraries, and pasted all the dll to the OpenStudio_ folder needed.

But it throws an exception on line 67:

Runtime error (IOException): file does not exist: C:\Users…\AppData\Roaming\Ladybug\OpenStudio_\openStudio.dll
line 67, in script

One thing is that the box link for the libraries give you a zip that does include a dll that looks very similar… except it’s cased differently: it is Upper Camel Case (OpenStudio.dll) and not Lower Camel Case (openStudio.dll)

Another thing is that even once I have renamed the above dll to match the casing, I still get this exception, even though os.path.isfile(os.path.join(openStudioLibFolder, “openStudio.dll”)) returns True.

If I type the path on the run command it does land at the appropriate file…

I’m confused, any ideas?

Hi Julien,

Can you make sure to unblock .dll files? The easiest way is to unblock the .zip file before extracting it. Right Click and you will see the option.

openstudio_ is my bad. I changed the folder on my system inside the file that I sent to you and I forgot to change it back. Drag the openstudio component from Honeybee tab and that should look for openstudio folder.

Yes. I think we should have it as the last item in the list for installation instruction.

Ah! Thanks!

For others, the “Unblock” is in the right click menu, under Properties and under the general tab at the bottom

I put it back in “%Appdata%\Ladybug\OpenStudio” and it worked without changing the casing.

But I do get an error.

Runtime error (TypeErrorException): prepareNonPlanarZone() got an unexpected keyword argument ‘meshingLevel’

line 2451, in main, “<string>”
line 2551, in script


That is a bug which I assume is fixed in the current version. Looks that you are using an older version of OpenStudio component. What is the date on the component?

ghenv.Component.Name = "Honeybee_Export To OpenStudio"
ghenv.Component.NickName = 'exportToOpenStudio’
ghenv.Component.Message = 'VER 0.0.56\nFEB_01_2015’
ghenv.Component.Category = "Honeybee"
ghenv.Component.SubCategory = “09 | Energy | Energy”
#compatibleHBVersion = VER 0.0.56\nFEB_01_2015
#compatibleLBVersion = VER 0.0.59\nFEB_01_2015
ghenv.Component.AdditionalHelpFromDocStrings = “1”

Is this version actually outdated then? I still can’t make it work.

Yes. There is a newer version for FEB_18_2015. I’m testing it now with nonplanar geometry to see if the issue is solved already.

It was a bug.

Find this line:

zone.prepareNonPlanarZone(meshingLevel = 1)

and remove meshingLevel = 1


or just use the attached file. The attached file is using the most updated version of Ladybug and Honeybee. You can use update components to get the latest version or just download it manually from github.

Thank you for reporting this,


PS: The new component should work for you but I think you should be able to model what you have all as planar surfaces.

updatedOpenStudio.gh (432 KB)

I updated the component, and I was still getting an error. Wouldn’t be fun otherwise… :slight_smile:

The error I was getting is:

Current working directory is set to: C:\Users…\AppData\Roaming\Ladybug\mall\OpenStudio
Analysis period is from 1 JAN to 31 DEC
Between hours 1:00 to 24:00

the space type is:OS:SpaceType,
{12884f42-3f62-4c4b-9d99-f321ff844e24}, !- Handle
Retail:Entry; !- Name

[… 47 other "space type is:OS:SpaceType …]

the space type is:OS:SpaceType,
{174829f0-0f70-40f5-b142-db610fc18b69}, !- Handle
Retail:Retail; !- Name

Runtime error (KeyNotFoundException): 3-Top-Bottom-Retail_Srf_1
line 1867, in setAdjacentSurfaces, “<string>”
line 2680, in main, “<string>”
line 2715, in script

It seems that it’s processing some space without problems, but doesn’t like this one one bit… After changing the name of the space, it worked.

Anyway, I can now export to openstudio. But it won’t load correctly in sketchup when I tried to open the exported .osm. Well, it does load, but it’s only wireframes… I tried running the openstudio diagnostic on it, without success.

Has anyone experienced that before?

I’ve attached the gh file with internalized data if someone would be extremely kind to take a look at it… (please don’t mention how bad the names I gave are… I’m aware :slight_smile: ), as well as the exported .osm.



PS: don’t be surprised if it takes some time to process… The solve adjacencies module takes about 2min to complete on my laptop)

Side note: I’ve never managed to make the Grizzlybear work for gbXML export… but that can wait until I try it on a simple shoe box…

2015-03-24_Mall.gh (1.92 MB)
mall.osm (2.18 MB)

Salut Julien,

I managed to open your osm file in OpenStudio and got it running the simulation. As the progress bar wasn’t growing I stopped it and then checked the err file. I figured out that there are many floors and roofs upside down (you better check the normal on these surfaces), many non-planar surfaces and many errors about wrong solar distribution (you should use FullExterior with non-convex zones, as you have a couple of l-shaped rooms). Please see the file attached.

I then opened your gh file and found a couple of brep missing (CenterWalkwayRoofRightSmall, the grazing surface of RightWingWalkway-Roof) and many of your zones recognized as open breps (see the HB Create Zone outputs) because you missed some walls: check the input geometries.

I hope I have been of help to you.

eplusout.err (1.04 MB)

Buongiorno Jacopo,

For some reason I can’t reply directly to your answer (must have reached the maximum reply limit), but yes this is helpful.

I had already checked the err file and I knew I had problems, but mostly I was freaked out by the fact that it was always in wireframe. I fixed a couple of things, including two HBZones that carried the same name and manage to import it in OS. Then I painfully and slowly cleaned everything in OpenStudio since all my attempts at doing it in Rhino had failed.

One thing is that I redrew the geometry using the architectural Rhino model as guide… Turns out the architectural model wasn’t very precise and a lot of stuff ended to be non planar.

These are Rhino questions and not a GH/HB one, but I’ll ask them anyway.

if I use “Planar” mode (command “planar” in Rhino), will that ensure my surfaces are planar or does object snapping take precedence?

Also, is there a way to force (transform/simplify) a closed brep with some non planar surfaces to only have planar surfaces? For example, I had a few boxes that had very minor offsets (<1cm) but turned out non planar as a result…

if I use “Planar” mode (command “planar” in Rhino), will that ensure my surfaces are planar or does object snapping take precedence?

All your lines will be drawn in the active Cplane so it won’t exactly do what are you looking for.

is there a way to force (transform/simplify) a closed brep with some non planar surfaces to only have planar surfaces? For example, I had a few boxes that had very minor offsets (<1cm) but turned out non planar as a result…

Yes. You can use Grasshopper to do that. There are more sophisticated solutions if you are willing to use plugins such as Kangaroo but the simplest way is to decompose the brep, get the plane for each face, project the original surfaces on that plane and join them back. The issue with this method is that it will more likely return an open Brep but there are solutions to address that too.

Hope it helps,


Hi again, I felt bad after I sent the previous response as I probably left you there with a day of work as a person who is getting started with Grasshopper. :slight_smile: Here is an example on how you can do it. It won’t work for crazy geometries but it should work fine for simple ones.

createPlanarClosedGeometry.gh (16.6 KB)

Interesting. That seems overcomplicated a little bit but does the job, thanks!


I am glad that you were able to get the model to run. To answer your Rhino questions, I will first say that it can be very easy to make bad geometry in Rhino, especially if you are a new user who is just learning how to use Rhino. Rhino offers great geometric freedom and power but, as they say, with great power comes great responsibility.

  1. Object snapping will always take precedence in Rhino over the Planar mode. So you really have to create your surfaces as planar from the start. Extruding curves and/or making boxes will always ensure planar surfaces.

  2. As I said, you really need to make sure that you make your geometry planar from the start. There’s no easy fix to turn all nonplanar surfaces into a planar ones but you should remember that triangles are always planar and, because of this, meshing will always produce planar geometries (or if you have a simple way of breaking up a surface into triangles, this will probably be better than automated meshing).



Your initial paragraph about making bad geometry and power = responsability resonates pretty strongly with me right now :slight_smile:

Lesson learned!

And thanks for your hard work and great tutorial videos.