algorithmic modeling for Rhino

This post is about 10 days overdue, but as they say, better late than never! Also this is two posts in one post. If you're not interested in the news about the new releases scroll down to the end of the post.

10 days ago was the 4th anniversary of the release of the first version of Ladybug and as the title says, I wanted to share with you what 2017 entails for Ladybug Analysis Tools (previously known as Ladybug + Honeybee).

In December 20016 at the AEC Tech Hackathon, I gave a presentation which pretty much covers all I need to write here. I’m copying the links to the videos so you can watch them and I will just highlight the most important topics. Here are the slides that I used for this presentation.

The first major release of 2017 is a new version of the original Ladybug + Honeybee plugins, which will hereafter be referred to as the legacy version of Ladybug Analysis Tools. Now that the plugins have been fully connected to the major open source engines and databases, the majority of changes represent “icing on the cake.” There are a number of new components related to maximizing the visual capabilities of Rhino, including contour map visualizations, components to make rendered animations, texture mapping components for transparent meshes (and connections to VR programs), and stereographic sky projections. Furthermore, the last of the thermal comfort models for local discomfort (drafts and radiant asymmetry) have been incorporated along with components that help calculate discomfort from given geometric and thermal criteria (a simplified downdraft model and a view factor component). There have been a few extensions of OpenStudio/E+ capabilities to get out HVAC system sizing results and to request/search through the hundreds of outputs that E+ offers. Finally, there are a few workflow improvements, including changes to use less memory when building large energy models and a workflow to import HBZones from gbXML. Chris has been leading the development for the legacy version during the last year or so and he deserves all the credits. There is no way to thank him enough for what he does on a daily basis. I can only say that we are all so lucky to have him around!

After the release of the legacy plugin, the next major release of 2017 will be the public release of Butterfly, which is already long overdue. If you are watching the project on GitHub, you should already know that we are very close and are trying to make the final improvements before the release. The release will have its own separate release notes. For now, I want to thank Theodore Galanos and everyone who helped us with their suggestions during the development process. There would be no Butterfly if it wasn’t for Theodore.

Butterfly’s release will be followed by the release of Honeybee[+]. The first release of Honeybee[+] supports most of the functionalities in the current version of Honeybee for daylight simulation plus it addresses many of the current limitations for annual daylight modeling by using Radiance 3-phase method. It should also support Grasshopper both on Windows and Mac as well as Dynamo. There is much more about Honeybee[+] which again will be included in a separate post. I want to thank Sarith Subramaniam and everyone who helped us with testing the code during the development. Honeybee[+] won’t have most of its features if it wasn’t for Sarith.

I also want to thank everyone on the forum who helps other users with questions and solutions. That’s how I and the rest of the developers get the time to focus on the new developments. Yet I didn’t get a chance to update the graph for this year but you know who you are. Thank you!

Finally, I am posting a modified draft from last year February. Chris and I drafted this post last year but never posted it as I was waiting for the “right time” to post it. The “right time” would be when we have free time to answer all the questions but that time seems not to come! We will do our best to reply to your comments as much as we can. Here is that post:


Even though we receive comments and ideas from many of you on a daily basis Tim's recent comment [it was recent at the time!] made me think that we should, once more, explicitly ask for your comments while developing the new version of Ladybug (and at some point Honeybee), and also collect the ongoing ones in a single place.

So post your comments, suggestions and wishes here and let us know what can we do to make Ladybug and Honeybee better. Any type of comments are welcome as far as you tell us why you think it is important. Here are a couple of questions to get you started:

- What is currently missing? Why do you think that missing feature is important?

- If you could only change one thing, what would it be and why?

- What do you like the most about Ladybug + Honeybee that you don't want to change in the new release?

- What kind of bottlenecks do you run into? - What have you done with Ladybug + Honeybee that you think it should/could have been done much simpler if we could have made a couple of changes?

- What do you think will be essential/missing from Ladybug for Dynamo?

- ...

Your turn! Let us know your thoughts!

Views: 3623

Replies are closed for this discussion.

Replies to This Discussion

First off: thanks for all you great work. You all deserve the highest respect for propelling these tools forward!

As a reply for your question "if you could gange one thing...":

Many of the analysis that are done with these tools are heavy and take a long time. A good way of showing a progressbar or even a way to stop an analysis would be the single biggest hurdle for me and the team at our office.

But once again thanks for all it already does!

Hi Enjar, Thanks for the kind words. I remember your discussion about this. The main issue for showing the progress is to know how much of the progress is already done. For radiance ray-tracing there is no easy way to do that. EnergyPlus and Rpict (Image-based) daylighting already generate some sort of reports. I assume your main request is for annual daylight analysis? In that case moving away from Daysim might actually help to find a solution. Sarith and I discussed the option to check the file size but haven't really tried it. I added a new issue to the new honeybee repository. You can follow the progress for this issue there:

Thank you Mostapha, Chris and everyone else who kindly spend a lot of time developing tools that we all use.

As far as suggestions go, I think one of the key elements missing on the HVAC side is the ability to do hybrid plant side simulations with systems like geothermal, solar hot water, combined heat and power, thermal storage etc. combined with more traditional boiler/chiller/tower equipment which might be less common now but certainly a useful addition in the years to come.

Hi Amir! Thanks for the kind words. Our plan is to leave the advanced HVAC modeling to OpenStudio measures. You will be able to load the measures into Grasshopper and apply them to your model. Is that going to address your needs?


To echo Mostapha's sentiment here, the world of HVAC (and especially very innovative HVAC) is so vast that we cannot possibly write all the scripts to enable this within the Honeybee community alone.  However, OpenStudio team has set up infrastructure for people to write custom ruby scripts with the OpenStudio API (called Measures) and simply run these scripts to apply highly custom, innovated HVAC systems to OpenStudio models.  What is even better is that they have set up the Building Components Library (BCL) so that people can share these scripts and the innovation of our community can grow!  Here is the list of scripts tat have been shared so far:[0]=im_field_measure_tags%3A956

After the (very soon) release of OpenStudio 2.0, the format for measures will be standardized and we will be able to finish a couple of components that allow you to apply measures to your model with Grasshopper (without the current bugs).  The biggest advantage of this workflow is that you can have custom inputs for each type of HVAC (ie. the number of boreholes on a Ground Source Heat Pump system).

Once OpenStudio team finishes this standardization, I have the working implementation of the "Run Measures" component as the last thing I will add to the legacy Honeybee before going full force on Honeybee[+].  Any future HVAC templates that I make for my office or other work (ie. GSHP system templates) will be implemented as Measures and shared through the OpenStudio BCL.


Exciting post and news Mostapha!!!

Thank you  ... and Happy 4th Birthday.


Thank you sir and thank you for supporting us during the last 4 years! Much appreciated.

First, thanks a lot to all the people who worked on Ladybug/Honeybee all these years, you made it wonderful !

Currently developing the use of these software in my company, i think that there could be several ways of simplifying things, especially for newcomers like me :

- correct some (or all) descriptions ! some small mistakes here and there put together can be very misleading for people like me at the beginning.

On the same level, maybe a guide/explanation on some parts could be nice (if it does exist, i'm interested :)). For instance i found controls for ventilation & lighting quite hard to play with at first compared to other tools because of the lack of info on this.


- It might be a WIP, but a tool to add/change some parameters could be nice. For instance temperature control based on operative T° instead of air T° or other very small things like that that could lead to a perfect customizable tool !

- Other small things:

component to add surface properties to shading/context geometries.

if possible: get the losses trough the envelope of the building to add to the energy balance.

change only one surface of an existing HBzone (maybe it is possible now actually)

Again, thanks for the great work you did with all this !

Hi Aurelien, Thank you for the kind words and the comments.

That's a fair comment and I remember Chris's main critique to the development once he joined the project was the descriptions. He has done a great job rewriting most of them but there is still a lot to be fixed. At the same time, as they say, people are blind to their own mistakes. We need the input from you or other users to get them fixed. If you can provide us a list of the descriptions that you think can be improved we will make sure to get them fixed in the next release.

Generally speaking we need better documentation but we have right now what is available is the primers. That should be a good place to start.

I think both of this comments takes an effort from the community more than the developers. We can definitely help to get it started like the primers but then making it perfect takes a group of people.

For the rest of your questions see my replies between the lines

- It might be a WIP, but a tool to add/change some parameters could be nice. For instance temperature control based on operative T° instead of air T° or other very small things like that that could lead to a perfect customizable tool !

Is it a request for set points in Energy simulation? Then it should be possible and I would open an issue for this on GitHub.

component to add surface properties to shading/context geometries.

EnergyPlus has limitations for how much you can set the properties for shading objects but there is room for improvement in this case. See this discussion.

if possible: get the losses trough the envelope of the building to add to the energy balance.

This is already there you can get the conduction both for transparent and opaque surfaces. Here is an example.

change only one surface of an existing HBzone (maybe it is possible now actually)

This is already possible. Try decomposeHBZone component!

Hi Mostapha,

I can't thank you enough for the time you put into HB and to answer all comments like mine :)

Hopefully I will have some time to get through the comments I found weird in the next weeks ! Should I creat a new discussion on the forum once I did that ?

for other issues :

- For T° controls, I think it is possible to specify the type of thermostat in the room such as this example :

"ZoneControl:Thermostat:OperativeTemperature, !- Defines zone temperature control type
Bloc1:Zone1 Thermostat, !- Thermostat name
Constant, !- Radiative Fraction Input Mode
0.50, !- Fixed Radiative Fraction
; !- Radiative Fraction Schedule Name

See also :

I am however not sure of the exact implication of such a change.

For shading geometries, I am using this method right now (thanks for this !)but just thought it could be simpler to add it to HB EP context surfaces component directly.

for the other questions, apologies foe the lack of work on my part :)



A new discussion sounds good! Maybe that encourages other people also to share their findings.

Thank you for adding the details. That's what I was thinking. I'm pretty sure Chris has some input on this topic. I have been thinking that we should add more zone control objects to HB in general. I remember that there was a similar request to use the comfort for zone control. Even if we don't implement it to the legacy version we should implement it to Honeybee[+].

Thank you very much, Mostapha, for sharing your talk!

Thank you, Chris and the whole development team for your hard work and great contributions!

- Ji






  • Add Photos
  • View All

© 2022   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service