algorithmic modeling for Rhino

- Orienting an imported window in plan seems difficult since it only accepts "horizontal" as an input for a plan-oriented window. Did I miss something or do I currently have to orient the outputs of the importWINDOW component?

- Currently the exporter does not allow to export without boundary conditions. I'd like to skip doing this in rhino because Therm actually seems a lot less hassle in this case since it has a one-click function.

Views: 1796

Replies are closed for this discussion.

Replies to This Discussion

Hi Derin,

Thanks for testing out the components and for your post.

The issue you raise about boundaries makes sense.  They really should be optional as they are not necessary in order to write the THERM file.  I just committed some updated components to the github that have made them optional:

You will also find these components in the attached example GH file.

I did not put in an option to change the angle of the window if it is in plan since I figured that, from a physics standpoint, all rotations of window sections in the XY plane would behave the same.  However, I realize that, if you want to coordinate your THERM model with other Rhino geometry, you might want to rotate these windows in plan.  Let me know if this is the reason why you would like to rotate the windows and I can find a way to work it in.



Thanks Chris! This has been a great help.

I'm actually not too concerned about the window orientation. Although the I don't think the physics is quite as simple as you suggest due to the position of coatings, interlayers, position of air cavities, etc., orientation afterwards seems to work without too much hassle.

However, the component is still too strict for a quick to Rhino to Therm workflow:

1. Geometry connected to _polygons does not have a single boundary (there are holes in the model).
These holes will cause THERM to crash.
Note that air gaps in your model whould be represented with a polygon having an 'air' material.

I'd like to use the paint bucket tool in Therm to fill voids rather than try to do it in grasshopper because it's a lot more difficult to write an algorithm to detect these voids than it is to simply click on them. 

Also (I'm not sure this warrants another thread), when I try to add an input to the "workingDir" of the writeTHERM, I get this error:

1. Solution exception:unsupported operand type(s) for +: 'NoneType' and 'str'


Thank you for all of the great feedback.  All of this is really helping improve the usability of the workflow.

I definitely understand that the orientation of coatings/interlayers/air cavities/BCs in relation to each other is important but I was under the impression that we were talking about the overall orientation of the whole model.  Let me know if I am misunderstanding.  I know that this overall model orientation in relation to the gravity arrow is important and this is why I allow you to put in any numerical orientation when your model is in the XZ plane.  But all models in the XY plane should have the same orientation with respect to the gravity arrow (no matter how the are rotated in that plane).  Do you know of any other parameters (like the gravity arrow) for which it is important to orient the model?  I realize that my own use of THERM is still pretty limited (I am usually only using it to get wintertime U-Values) and any knowledge that you could share is much appreciated.

You're case for the export of models with holes makes sense.  I had gotten a little too obsessed with developing a purely Rhino/GH workflow that I did not give enough credit to the things that are easy to do in THERM, (like the paint bucket).  You can now export models with holes in them to THERM as you see here in the attached file:

I am still leaving in the warning on the component just so that new users are aware of the possible workflows but the .thmx file is written.

Lastly, that workingDir issue was a bug that I have just fixed (see github and attached file):

Thanks for finding it and let me know if you have any other suggestions.



Hi Chris,

I've enjoyed experimenting with these new tools and it seems to open up some interesting new workflows. One question I have, related to the earlier discussions, is to do with the insertion of elements created in Window:

In Therm, when you insert a Window component you have the option to orient it 'up', 'down', 'left or 'right' which allows you to use the glazing systems in a range of different scenarios. The grasshopper component only seems to allow you insert the elements in the 'up' orientation, with some planar rotation.

Is it possible to replicate this insertion functionality within grasshopper? At the moment I cant see how you would model the top of a window frame without manipulating the window geometry natively in Therm after export.

Many thanks


Hi Mike,

Thank you greatly for the feedback.  Derin's and your thoughts are really helping refine the components. Now that I am understanding the hybrid workflows between the Honeybee components and current THERM capabilities, I wholeheartedly agree that the current means of inserting the WINDOW glazing system is far from ideal.

I think that I may have found an implementation that allows for both an clear parallel with current THERM workflows but also affords the geometric flexibility that I was originally hoping to include with the ability to set any angle (not just the 4 orthogonal orientations).  Just to explain briefly the importance of the flexibility, it is possible and even common to have glazing systems that are at an slant to the vertical and, in a purely THERM workflow, you could just rotate the whole THERM model with glazing system before you draw the frame.  This same process will not work if you are drawing your frame in Rhino before exporting to THERM unless you have some means of rotating the glazing system geometry in Rhino/Grasshopper before your frame-drawing.

Now to explain the implementation:

The _orientation_ input of the "Import WINDOW Glz System" component now takes one of four integer values, which reference the typical means of importing a glazing system into THERM:

0 = Up
1 = Down
2 = Left
3 = Right

The _location_ input still has the same functionality to set a point for the location of the glazing system.  However this input can now also be a plane that sets the entire reference for the glazing system.  In this manner, you can rotate a plane before inputting it into the component to get any slant that you want.  In this example, I just set the plane to be the WorldXZ instead of the default WorldXY:

See the attached file to use the updated component and let me know your thoughts on this.

Thanks again!



Thanks Chris, this is all fantastic and resolves the issue of Window insertion. Although I haven't had a great need to use rotated glazing systems within Therm, I understand the importance of allowing this functionality.

One further question that has come up in our experiments relates to the creation of Therm materials directly in Grasshopper. The frame cavity materials in the default Therm library have properties related to the cavity itself, such as 'Gas Fill' and 'Cavity Model' which define how the cavity is considered in the final analysis.

It would be interesting to know if these properties could be added to the properties that are defined in material creation in Grasshopper, so that both solids and cavities could be created from scratch.

Thanks again for the prompt response!



I looked deeper into your suggestion about creating custom frame cavity materials in Grasshopper.  It turns out that it is relatively easy to set the 'Cavity Model' of a custom gas material.  However, LBNL has not yet implemented the ability to define the 'Gas Fill' from a .THMX file (all custom frame cavity models just default to air materials).  As I understand it, there are a few features that the LBNL team has not implemented yet on the .THMX file type, which it is planning to implement in the future:

1) Ability to set 'Gas Fill' of materials other than air in a .thmx file

2) The ability to set the Gravity Arrow from the .thmx file

3) The ability to associate .thmx files with THERM and have them automatically open when double-clicked (this will save us from having to open  THERM and navigate to the thmx file every time we want to bring it in).

I am hoping that the Honeybee components will give LBNL a good reason to implement these features on the thmx file soon.  I plan to send the LBNL team an email about these critical missing capabilities.

To be in line with the current limitations that LBNL has set for the time being, I have changed the type_ input on the "Honeybee_Therm Material" component to be cavityModel_ instead.  This way, you can set a cavity model if you are creating a gas material or you can just leave it blank to create a solid material.

I should also mention that, if you are using the "Import from WINDOW" workflow, the THERM polygons for the glazing system will automatically account for the gas fill by using the "effective conductivity" of the gas that WINDOW computes for you.  This is what THERM does when you import a glazing system (THERM doesn't create a custom frame cavity material and set the gas.  It just uses this effective conductivity).

Given that most exotic gasses get used between window panes and not in the frame cavities, the current capabilities should hopefully satisfy most needs.  Still, it doesn't hurt to put a bit of pressure on LBNL to implement the features above.



Hi Chris,

Is there a way to have the importTHERM component output the therm material for each polygon? That way it should be easy to go back and forth.

Chris, thanks for your help. I will put it to the test get back to you. 

Hi Derin,

Although I've never used therm stuff here yet I got a hint of how it may work.

Anyway, since it is all 2D when you mentioned paint bucket I thought about curve boolean in rhino that functions kinda like it (click to pick enclosed portions of the plan).

Hope it will work the way you want, otherwise I have no idea XD.






  • Add Photos
  • View All


  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service