I attempted to utilize the HB energy shade benefit evaluator in LBT as my Legacy version is no longer functional. @chris, do you have a workaround to adapt your excellent definition to LBT?
I’ve included my Grasshopper script here, and I hope it aids in resolving the issue.
The shade benefit workflows were on my agenda for the next release and I have already started work on the thermal comfort shade benefit component, which is the sister component to the one that you are pointing out there.
I have a few planned improvements for the energy shade benefit in particular, which will make it easier to run with large models. For one, I’m planning to write it in a way that evaluates all shades that are assigned to windows, which will make it clear for which window each shade is being evaluated.
The sun shades calculator is not part of theLBT. We (@AntonelloDiNunzio and myself) developed it at the time and it was included in the Legacy version.
The good news is that you can still use it since it doesn’t requiere any of the LBT libraries, it works independently. The outputs can be plugged into the shades of the model.
The bad news are that there are some bugs that are still unresolved.
-A.
Thanks for the clarification. It’s an amazing component, I hope you will be able to solve the bugs at some point.
I’ve observed that it functions well for me as long as I don’t add any context to the input. However, whenever I incorporate any type of context to the input, I encounter the following error messages:
Seems to be that the shading surface doesn’t intersect any sun vector.
If you are giving a surface for the shadeSurface_ input, be sure that it will affect your window.
No enough intersection points to calculate the shading surface
FYI, you can see here that I just added the comfort shade benefit component to the LBT development version yesterday:
So you can expect the energy shade benefit capability to be added soon.
I was not planning to bring the Shading Designer component over from Legacy because most of the things that it does are better addressed with other new components. If you are tying to use the Legacy Ladybug Shading Designer to generate louver shades or overhangs, I would recommend the HB Louver Shades component. FYI, this is the component that will be used in the new energy shade benefit workflows that I have in mind.
If you’re trying to use the shading designer for its ability to generate a shade geometry that blocks a set of sun vectors, I just added a more generalized “LB Shade Benefit” component that does an analysis like this except with a more practical result that quantifies which parts of the shade geometry are blocking the most sun vectors. You can use this to perform a wider variety of shade studies like evaluating which parts of a shade might be most useful for blocking direct sun and mitigating glare:
And, instead of having to create a shade that blocks all of the sun vectors (which is often impractically large), you can make an “optimized” one that blocks the most suns within a given area.
Granted, if you give this new component the right set of inputs, you also can do what the legacy shading designer did of making a shade that blocks all suns.
Hi @tru ,
No. This is not a bug. In this case seems to be a misunderstanding on the context input. Your context is located at the same location as the shading element is supposed to be calculated (just above the window limits). If you disconnect your geometry you get this:
Some of the bugs are related to the option of plotting pergola shadings, which not always work as expected. That seems to be caused by some change on Rhino at some release, and i didn’t succeed in identifying to solve it. There are probably more that i don’t remember now.
Attached your file with the latest version of the component.
Thank you so much for the incredibly prompt response and the detailed explanation of the workflow. I’m delighted to start using the new components you’ve just developed.
Thank you for the explanation. My intention was to utilize a hypothetical volume of the same building as a context to test the self-shading on the new surface shading. Now I can confirm that it works. I believe in one of my earlier tests, not the one I posted, I might have selected a geometry that is in the same plane as you mentioned.
The workflow is a lot more streamlined compared to Legacy now that we can assign Shades to Apertures and use that as the means to identify which aperture affects which shade. And it was good to re-evaluate how we were calculating the benefit since I realized that it only took a small tweak to my old code to get the net heating/cooling load savings in kWh by postprocessing the results:
This also marks the point where I can at last I can say that every single energy simulation feature that existed in Legacy is in the LBT plugin. It may have taken 4 years of development to get here but it still feels good to hit the milestone.
Thank you so much for the update and for putting in a significant effort to consistently update and enhance the tool. I’m delighted to hear that all the energy features are now integrated into LBT.