Ladybug Analysis Tools in 2017!

announcements
1

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!

1 Like
2

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!

3

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.

4

Exciting post and news Mostapha!!!

Thank you … and Happy 4th Birthday.

-A.

5

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 !

6

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: https://github.com/ladybug-analysis-tools/honeybee/issues/120

7

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?

8

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

9

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!

10

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
11

Hi Mostapha,

Great work done by developing such wonderful tools.

I have a suggestion for WindRose Component.

As per attached image,

Outer two lines indicate Wind Speed and Frequency respectively.

Being an analyst, we are aware about what they indicate, but for a reviewer it is harder to understand.

Providing a legend for that would make that data easily understandable.

Some solution I have come up with is as per image below:

Keep up the great work.

Thanks,

Bijit.

12

Hi Mostapha,

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

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 : http://bigladdersoftware.com/epx/docs/8-4/input-output-reference/gr…

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

Best,

A.

13

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.

14

Hi Bijit, Thanks! I leave making the decision on this one to Devang. He has implemented all the latest improvements for WindRose. What if we just color the text? The colored geometries might be confusing as we have a colorful legend.

15

Thank you Ji for the nice comment and your great work. Always inspiring!

16

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[+].

17

That would be great Mostapha, Thanks a lot.

And yes, I support your argument about providing color to text.

Looking forward for the update, Devang Chauhan.

Best,

Bijit.

18

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.

19

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

King regards.

-Omid

20

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,
-Devang