Apertures by floor area

1

Hi @chris,
As a complement for this discussion I’m writing a component to set the apertures size as a function of the room area. It also avoids inserting apertures when the length of the wall is shorter than a desired input.

I get to the point it is working but not smoothly.
For instance in order to get updated from input changes i need to disable/enable the component. Otherwise it keeps the previous definitions. Can’t get why this is happening.

Also i’m not sure how efficient the code is. I took a few parts from existing components and a lot from the SDK guides. That’s why i believe it can be optimized and shortened.

Will appreciate if you can have a look at it and tell me your thoughts.

Attached the file with the definition and a simple example.

Thanks a lot!!
-A.
ApertureFromFloorArea.gh (45.8 KB)

2 Likes
2

Another bug i’ve noticed is that the operable attribute is always set to on, even though the input is set to False.
-A.

3

Hi,
Just in case this fell between the cracks …
-A.

4

Hey @AbrahamYezioro ,

You are editing the input Rooms instead of editing the output Rooms:

image
image755×388 11.7 KB

So that’s why you were getting all sorts of weird behavior. Just change it to loop through hb_objs instead of _hb_objs and it seems to work as expected.

ApertureFromFloorArea_CWM.gh (35.0 KB)

1 Like
5

Ahhhhhhhhrrrrgggh! So silly.
Thanks @chris. There are a couple more things i want to ask:

  1. I can’t get the operable attribute to be assigned. This is how i tried but it is always True:
                    wFace.apertures_by_ratio(west_win_par, tolerance)
                # try to assign the operable property
                if operable_:
                    for ap in wFace.apertures:
                        ap.is_operable = operable_
  1. The glz_ratios output need to have a Tree structure. I’m using the GH way to define trees, but i believe the LBT SDK is using some internal functions to do that more transparent, from the coding point of view. Is this true? If so, can you share some pointers how to do that?

Attached a more updated version of the code.

Thanks again @chris!

-A.
ApertureFromFloorArea_01.gh (68.4 KB)

6

It looks like operable_ is a list:

image
image840×304 14.9 KB

So the statement if operable_ is always going to evaluate to True. Maybe you should change the operable_ input to item access and get rid of this operable_ = operable_ if len(operable_) != 0 else [False] line.

There’s an easy way to convert lists of lists into Grasshopper DataTree objects using this list_to_data_tree method within ladybug_rhino.grassopper:

https://www.ladybug.tools/ladybug-rhino/docs/ladybug_rhino.grasshopper.html#ladybug_rhino.grasshopper.list_to_data_tree

1 Like
7

This is it!!! Thanks a lot @chris I took the definition (list) from the AperturesByRatio component. Wasn’t thinking about the implications.

Just FYI, i added the possibility to define the glazing ratio from floor area, either gross or net, thanks to the new function you just added in the HB Geometry Properties component.
Our local codes require to define window size according to floor area. So this is why I’m looking for this.

Now i am in doubt if to output the glazing ratios and use the LBT apertures by ratio or keep outputting the HB objects with the windows in them. The other capabilities in this component might be important/useful, and i’m not sure if it will be smart to repeat them in my definitions.

In any case, i’ll post the latest definition after i implement the LBT trees capabilities.

Thanks again. Your help was proven, again, to be super valuable.

-A.

1 Like