"Stacked" HB Louver Shades Components

grasshopper honeybee
, ,
1

Hi all, I’m attempting to build out a shoebox model that can rapidly generate a single room model for daylight & energy analysis…

I’d Ideally like to have everything pre-populated and super easy to use. With that said, I got the idea to have multiple “HB Louver Shades”, one for overhangs and one for vertical fins (and in some cases we’d like to model both simultaneously).

Everything seemed to be working, until I tried to input the room into the “HB Peak Loads” and “HB Annual Loads” components. As i get the following error:

  1. Solution exception: ** Fatal ** Errors occurred on processing input file. Preceding condition(s) cause termination.

Upon further investigation, I found two things…

  1. It works if I only use one “HB Louver Shades” component…
  2. The components are using repetitive names for the shading elements. Assuming this was the issue, my next idea was to peel the shades off, rename them, and feed them to the HB loads components separate from the rooms.

Now it seems like I’m unable to rename the shades using the “HB Set Identifier” component.

Any one have any ideas of how to remedy this workflow?
As always, any suggestions are very much appreciated!

image
image2294×1021 409 KB

image
image1808×1052 169 KB

2

Hey @jakechevrier ,

This is a good question and there’s a really easy way to avoid this case on the SDK method that is being used to generate the louver shades. Specifically, you’ll see that this Aperture.louver_by_distance_between() method that is being used to generate the lover shades has a base_name input argument, which can be used to customize the names of the shades being generated.

So, if you just modify the following lines in one of of the components:

… to be something like the following:

if dist is None:
    louvers = ap.louvers_by_count(
        count, depth, off, angle, vec, flip, indr, tolerance,
        base_name='Overhang')
else:
    louvers = ap.louvers_by_distance_between(
        dist, depth, off, angle, vec, flip, indr, tolerance,
        max_count=count, base_name='Overhang')

Then, everything will work. So this will give you something that can work around the issue.

For a long term-solution, I am not sure if this situation is common enough that it merits a change to the official component but we can expose the base_name as a component input if it becomes enough of a headache for people.

1 Like
3

Perfect, thank you for sharing this! This solved the problem with the peak & annual loads components!

Note: You indirectly led me to search the SDK (teaching me how to fish :smiley: ), as “basename” was not working, but found it needs to be “base_name” from the SDK.

Its funny how comfortable I feel in GH, but quickly feel so out of my element in traditional programming having never received formal training. I’m sure you have much more important things on your plate, but have you ever considered doing basic Python/SDK/Github explanations and tutorials? I have to say I love your videos, you’re a really great teacher and I’ve learned so much from your GH/LBT tutorials. I feel like a beginner LBT developer series would be extremely valuable, especially with the new pollination app interface rolling out.

2 Likes
4

Glad that this addressed your issue, @jakechevrier .

Ah, thanks for finding my typo. I just fixed it in the sample I pasted above.

Yea, this is definitely a topic that I would like to eventually teach and it will be a lot nicer to do something like this now that we have a clearly-structured SDK for Ladybug Tools. I know that we’ll be gearing up to teach workshops on creating your own Pollination Apps, which also tend to use the Ladybug Tools SDK. I imagine that a nice tutorial would start with something mocked up in Grasshopper and then walk through wrapping it up in a single Grasshopper component and then an App. Just because it’s a new topic, it will probably be a while before we have a freely available video series covering all of this. If your office is looking to get ahead of the curve, we could probably do this sooner through a workshop or as part of the enterprise partnership that we’re now offering through our Pollination Services.

2 Likes
5

Hi Chris!
Just going to second that this type of error has got me also!

I feel it’s quite natural to use the Louver Shade component for a window once you know it’s there - but I also think that it’s natural to want to use the same component with the parent aperture as a guide to create multiple fins however you want.
I created my shading geometry and everything seemed to be fine up until this point and so maybe a note to warn that the HB Louver Shades component can only be applied once would be helpful.

Rather than use the component i might revert to breaking down Breps which i feel is a lot less clean than what this component promises.

6

Fair enough, @LeightonSS55 . Now that I can see that this has caused an issue more than 3 times, I just made a change to make sure that the IDs of the louvers never conflict with one another when used sequentially:

1 Like