Ladybug Analysis Tools in 2017!

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!

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Devang Chauhan on January 28, 2017 at 4:26pm

Implemented.

The native mesh Color component is just what we needed. I wasn't aware of that one. Thanks for bringing it to attention Chris.

Permalink Reply by Bijit on January 29, 2017 at 10:37pm

Hello Everyone,

This sounds good to me,

Thanks Mostapha, Devang and Chris for giving time to this concern.

Cheers

-Bijit

Permalink Reply by Pin on January 24, 2017 at 6:05am

Sounds exciting!

I have some ideas for the simplification of future development, but I think they're more on the E+ side of the code and if the NREL team would agree to implement new features. I have no idea though how to communicate these ideas so it might be better to post it here first.

I was wondering if it was possible for the the E+ team to have some sort of API to allow the simplification of creating/concatenating the lines required for the IDF files because although it's not extremely difficult to write the concatenation code in Python, I imagine that it can become tedious with all the copy-pasting and creating dictionaries for valid input.

At the same time, coders have to re-implement the exception handling that I imagine is already present in the IDF editor (i.e. when invalid values are entered, the boxes turn red).

For example, for a component that has 'timestep' as an input, the developers might have to implement some code to make sure that the values are between 1 and 60; which happens to be a built in function of the IDF Editor.

I think the current components are fine as they are, but sometimes, implementing some classes not yet present in HB from E+ can be tedious especially if the E+ class requires a lot of inputs.

----------------

In pseudocode, I'm thinking of something like this: (maybe similar to the class RunIDF of Run E+ component?, but I'm not really sure)

# write some sort of file with instructions to a batch file maybe? maybe the first line pertains to the class name

# The rest may be comma separated values? One E+ object per line?

# For example, this data is sent:

Shadow Calculation

Calculation Method, AverageOverDaysInFrequency

Calculation Frequency, 30

# Then the API returns the correctly formatted string ready to be written in the IDF file?

# If the user has entered invalid input, then the API returns some error messages similar to how the boxes turn red inside the IDF editor

Some advantages I can think of:

- for example if the E+ version changes with changes to the ranges of valid inputs, none of the code has to be changed

- if the E+ version changes with additional objects to previous classes, then minimal code changes?

I'm not sure though if this'd be difficult or tedious for the E+ team to implement, but I honestly think it that it'd make life easier for us. Not sure if this would be of any benefit to the E+ team though.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 25, 2017 at 4:36pm

Hi Pin,

1. What about using OpenStudio API? That basically does what you say and you can see an example in OpenStudio component in Honeybee.

2. Do you want to have a report while writing the idf file for all the assumptions? That should be similar to what Olivier is asking for. I'll discuss it under his comment.

Permalink Reply by Pin on January 26, 2017 at 5:08am

Hi Mostapha,

Thanks, I guess I really have to learn about OpenStudio.

I have some questions regarding HB+.

1. Is it intended to replace the old HB at some point?

If it is, then a lot of the code has to be rewritten right? Maybe we could help at some point? I think this would be a good opportunity for developers to learn the inner workings of LB/HB. I'm particularly interested in participating.

2. I've been browsing through the code of HB+ (I'm assuming it's this: https://github.com/ladybug-analysis-tools/honeybee-plus), and I have to say that it looks really great with all the docstrings, PEP8 and even its own API documentation.

I was wondering if this is meant to work with a later version of GhPython/GH/Rhino (Rhino 6 maybe?). I remember from your video tutorials for developers... you've mentioned that at the moment, sc.sticky was used instead of import libraries due to some reasons.

For some reason, we're going the normal way of development. Maybe it's related to the upcoming Rhino 6? (I remember something like GH would already be part of Rhino with a better Python implementation or something like that).

Permalink Reply by Chris Mackey on January 28, 2017 at 1:08pm

Pin,

To answer your questions:

1. Yes, HB+ will replace the legacy version (the "current" one) at some point, although it will be at least several months before all of the features of the legacy version are in the plus version. Stay tuned to that github to find way to get involved.

2. HB[+] is intended to work with many different versions of python, including ironPython (that which is used by Rhino 5 and Rhino 6), Python 2.7, and all of the way to Python 3.6. There will be no need to let HB_HB fly or to use sticky as most code will be in external .py files. As such, it will be cross-platform. See here for the list of reasons why the code is being re-written:

https://github.com/ladybug-analysis-tools/honeybee/issues/122

I hope this helps clarify,

-Chris

Permalink Reply by Mostapha Sadeghipour Roudsari on January 29, 2017 at 9:36am

2. HB[+] won't work with Python 3. Maybe that's something that we should start to consider before it gets very late.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 29, 2017 at 9:39am

Hi Pin,

1. Just to add to Chris's reply, once we get the first release out it's a top priority to get more developers involved in the process of development. I haven't written down the guidelines for that yet.

Permalink Reply by Pin on January 30, 2017 at 6:37am

Hi Chris and Mostapha,

Thanks! I look forward to helping in the development.

Just one last clarification.

Since Python 3 has been mentioned (and implied that HB[+] can be made do work with Py3+), does that mean that the Rhino team is planning on adding other implementations of Python? (CPython maybe?) (Since Rhino5 is limited to 2.7 because it's using IronPython).

Permalink Reply by Mostapha Sadeghipour Roudsari on January 30, 2017 at 7:13am

For some reason the website removed all the reply except for the link. Check this slides or watch the presentation to see how and why the python binding will be useful. It's not for Rhino/Grasshopper.

Permalink Reply by Olivier Dambron on January 24, 2017 at 3:39pm

Hi Mostapha,

The ripple effect of Givers is very real. You, Chris, Sarith, Theodore and this movement are enhancing the success of people around. Thank you, long live the bugs!

A quick idea on what I would find a useful addition, perhaps to generate a recapitulative table of all the parameters set in a simulation run and their assigned values. This would help monitor the overall coherence of thermal, daylight and natural ventilation analysis and foster users to develop their critical views to assess meaningful results.

Permalink Reply by Mostapha Sadeghipour Roudsari on January 25, 2017 at 4:40pm

Hi Olivier, Thank you for the kind comments.

I love the idea of having an input summary form but is it only include what the user inputs from GH interface? Or all the inputs? In a sense idf is the list of all the inputs. How do you think we should abstract that data to make it useful?