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: 3251

Replies are closed for this discussion.

Replies to This Discussion

I like this idea of catching all the parameters.

Thanks a lot for the support and great development work (more than work).

King regards.


Hi Omid! Thanks for your comment and thank you for helping other users on the forum.

Mostapha Sadeghipour Roudsari,

This is inspiring and great as always. Many congratulations to you on the 4th anniversary. Thank you for everything. Also, a big thanks to Chris Mackey for spearheading the development of Legacy versions. I believe that had a direct impact on the development of Butterfly, Dynamo variants, and Plus variants.

I have been thinking about providing feedback since the day it was posted. I will put my thought to words.

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

1. Checklists and notes. I got this idea from a checklist for Daylight simulation from Prof. Christoph Reinhart. Ladybug Analysis Tools is a community of experts. What if there's a way for people to make such checklists/notes and share with everyone. For instance, one would be very interested in looking at a checklist/notes from Sarith, Chris and you before commencing a daylight / electric light simulation. Similarly, a checklist for CFD simulation can come from Theodore and you. And there could be many such checklists. I believe this could be really helpful to the beginners. Maybe, it can have an effect on initial time spent on establishing workflows.

2. Test cases for developers. This is something I have already shared with you and Chris. The idea is to have test cases for a developer to run before he/she submits the changes in the script. This is one way to make sure that the original capabilities of the component are not harmed by the new implementation.

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

1. I would go and write Docstring for all the function definitions. Till now I have only worked on components developed by other developers. Obviously, this is something I felt should be there. Maybe this could be done in the Plus variants you are writing.

2. I am also in complete agreement with Aurelien Keller about his comment on descriptions. This is necessary, and I am too working towards improving tool tip descriptions and component descriptions as and when I spot the ones that I think could be improved.

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

I really like the toolset approach. I believe that should be retained.

I have no definite answers to the rest of three questions, but will surely comment if I think of something.

Kind Regards,

2. I am also in complete agreement with Aurelien Keller about his comment on descriptions. This is necessary, and I am too working towards improving tool tip descriptions and component descriptions as and when I spot the ones that I think could be improved.

What I really like is adding what decision the component can help you take in addition what it can help you simulate. Obviously, I draw inspiration from components written by Chris and Sarith. Technical notes, suggested practices, and warnings provided by Sarith are much appreciated.

Hi Devang, Thank you for the detailed reply. Great suggestions.


1. Can you share an example of the checklist? I would say the better idea is to create quality-check components based on these checklists/best practice approaches. We can definitely implement this in [+] components. For CFD Ilker had a similar idea but for post processing the results and give feedback based on the accuracy of the results.

2. Testing inside Grasshopper is challenging. We started it here but then it stopped. For the python code itself it's must and we are already writing tests for the new development.


1. Totally! The new development is well documented and that's how we're generating this API documentation. It might be too much work for the legacy version, and also if everything goes as planned we should retire the legacy version at some point soon.

2. Thanks!


Thank you for the feedback! Really helpful.

Hi Mostapha,

I have attached the checklist that gave me the idea. It is too old. Now that you have mentioned, I like the idea of creating components more. Do we have any such component already in LB+HB? If yes, I would be interested.



Thank you for the list. Such lists can be really helpful. We don't have any at the moment. Honeybee[+] is trying to address some of the items in your checklist specially for the results visualization. Automating some of the items is going to be hard as we don't have all the information that we need. For instance how do we know if there is a ground plane? At the same time we can create components to help the users to take care of the cases. For instance have a component/option that adds the ground plane to the scene. There is a lot that we can do in that area. To me that's a turning point once we can include the best practice into the workflow.


Great news!!! So happy with that.

One thing, I don't know if its possible or how difficult would it be, so just asking.

Would it be possible to make more clear the additional results from Energy plus?

I'll try to explain my self.

I've been spending a lot of time developing a way to use Air flow network directly in grasshopper instead of  running the simulation, editing the .idf and reloading it. I plug it in the additional strings of the run energy simulation and then I get the air flow volume (ach) from the "Other zone data" in "Read result" and the opening factors and multiplier of the windows from the "other surf data" in "Read EPS Srf results" all of them quite mixed, but its easy to separate them, so not a real problem with that.

However, some other outputs that I'm also including, such as the wind pressure on the windows surfaces don't appear (or I haven't found), I need to get into the excel .

It would be quite helpful

Hi Julia, Thank you for the suggestions.

1. I know this is not your request but we should fully implement airflow network to honeybee.

2.Yes. We have been talking about this. The most straight forward approach is to generate the sql file. We even get it started but then we closed it as I thought no one will be really use it. I will go ahead and re-open the issue so we implement this to Honeybee[+] now that we know we're not going to be the only users!

Thanks a lot Mostapha,

At least for me it will be extremely helpful.

About developing AFN, I'm not sure yet about how worthy is to use it. The main advantage I'm seeing right now is that it gives data of the air flow between different zones, what can be extremely useful. But I don't completely trust yet my results. So, if you develop it one day, I'll really love to test it and see what I've been doing right and wrong.


Thank you for the recognition!  It is always good to feel appreciated :)


Thank you for the comment and I should have put up an example sooner about how you can get custom outputs for anything you want with Honeybee.  The SQL is one method that we have not fully implemented yet but will usually take SOOOOO long to write because E+ will write all of this crud into the SQL that you are usually not interested in.  A better approach in my view is to run the model once and parse the Result Data Dictionary (.rdd) file using the "Honeybee_Read Result Dictionary" component.  This allows you to see all of the outputs that you can request and you can even search through it to find a particular output.  Once you find what you are looking for, you simply copy the text into a panel and and plug this into simulationOutputs.  Then you can use the "Honeybee_Read EP Custom Result" component to bring the results that you are interested into GH.  I updated the example of the evaportaive cooling tower on Hydra (which already shows how to use additionalStrings) in order to show how to get out a custom output of the energy removed by the tower:

I am going to close the SQL github issue now unless someone has a specific reason why the SQL method is better than the method that I posted here.  If you don't mind, Mostapha, will you direct people who ask questions about custom results to this example file for the time being? If we implement SQL, I don't see it happening until on the legacy version of HB.







  • Add Photos
  • View All

© 2020   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service