This is great @chris. Thanks a lot. Looks so “easy”.
I think there are a couple of bugs when you have 2 rooms (or more i guess):
As a previous issue the result is affected by the order of the base geometry.
Windows are missing in one or both rooms or are defined on interior walls. This can be connected to the previous one but didn’t get a clear conclusion so far.
Please see the attached. The geometries are on the top-left side of the canvas. Also added the adjacency component.
Thanks,
-A. TestScriptForAbraham_AY02_CWM.gh (87.2 KB)
As you see in the sample files, you need to intersect the Room2Ds before you solve adjacencies between them. Otherwise the adjacent segments won’t have matching lengths. So here’s the correct way to do it:
Maybe I should just automatically intersect the segments within the adjacency-setting component so that this mistake doesn’t happen again (and we can get rid of the intersection component). I guess the main reason why we pulled out the intersection in Honeybee is because the intersection calculation can be really computationally intense in 3D space. But it’s a lot quicker when it’s all in 2D space and the times where someone wants to solve Room2D adjacency but doesn’t want the intersection are pretty rare. What do you think?
I think i should pay more attention. Don’t believe it is necessary to add the automatic intersection. In this way it preserves the “normal” workflow in DF. Also the computation intensity should be preserved low as possible. So, it is excellent as it is now.
I really appreciate your help in this one (but not only). My workflows are almost translated to [+]. This one was the most difficult to achieve.
Hi @chris,
One more thing. Tried to implement the shd_par input in the code. My success is partial but i believe it is not working right. Can you take a look? It is in the yellow group.
Just copied code from the DF_ApplyFacadePar component and included some of the libraries. For sure i’m missing some things.
Hey @AbrahamYezioro ,
Nice! You were almost there with the shading parameters. The only thing that I had to change is that you were editing the Room2Ds that were input into the component instead of the Room2Ds that are output from the component. It all really comes down to understanding what’s happening in these few lines of the code that I originally wrote:
# assign the window parameters to the output room
new_room = room.duplicate() # duplicate to avoid editing component input
new_room.window_parameters = win_par
room2ds.append(new_room)
That duplicate() method is something that virtually all Honeybee and Dragonfly objects have and it’s pretty important if you want to build your own Grasshopper components. Essentially, it just makes a copy of the original object such that you can edit this copy (eg. assign some new window parameters or shading parameters) and the original object will not be changed. This helps preserve the fundamental logic of the Honeybee Grasshopper plugin where you input a given object to a component and get a new, edited object output from the component. Importantly, you still have the old object in it’s un-edited state if you look at the output of the previous component. What you were doing in your script, though, was editing this input object and, therefore, it breaks this Grasshopper logic.
In legacy, I think we named this process of duplicating the object “Calling from Honeybee Hive” and it was way more complicated than it needed to be. If you just remember to call this duplicate() method in [+], you should be all set to make your own Grasshopper components.
One thing i was thinking is an error is that for options Overhang and Louver the shade will be constrained to the window size while it is taking the whole wall surface. Maybe it is better this way, it’s just the icon that confused me.
Thanks again and i’ll think on another challenge …
-A.
And, no that’s not an error but it’s just the way that those particular ShadingParameters were written. It isn’t that hard to add a new ShadingParameter class to the core libraries that can add an overhang over each individual window instead of the parent Face. If it’s something that you’d like, feel free to open a “Wish” issue for it on the dragonfly-core repo:
Thinking about it i think is much better as it is now (shades on the wall surface) instead on a per window base. Just imagine 2 windows, different sizes with the same parameters. This will be a messy facade.
Maybe it can be a nice addition, but for now, not something i wish for.
-A.
Hi @chris,
I was thinking about something and before i open a “wish”, wanted to see what do you think.
The shades are created on each facade (is fine). The thing is that they are created regardless they have any window on them. Here i’m not sure it is desired.
So i want to hear your comments on this and understand the logic.
My wish will be to decide whether or not to create shades on facades without windows.
Makes sense?
-A.
I thought from the way you set up your original code that you wanted to assign the shading parameters independently of the windows. But here’s a GH file with an updated component that only applies the ShadingParameters to the walls where there are windows:
I should have known you also wanted to account for the case where the users sets the ratio to be 0 instead of just the cases where the segment is too short. Here’s the updated sample: TestScriptForAbraham_AY03_CWM04.gh (53.5 KB)
Hi again @chris for this discussion.
Following other topics regarding whether to work with DF or HB, i wanted to translate the code above to HB. Unfortunately i’m struggling quite some time and right now i’m kind of stuck.
I think i get some of the parts but others i can’t find the parallel HB version. See point 3. in the attached. The fie has both tracks (above-DF, below-HB).
In point 4., BTW, I am trying to “code” the different attributes of the rooms in HB.
Also wanted to ask you advice whether is better to output the zones with the windows, as in your code, or just the ratios as a tree branch per room. The advantage i see from the later is that i can connect the values with the other win_par options.
There are a couple of issues in the attached file that maybe you can help:
The DF version is not outputting the roof as exterior surface. It is a ceiling. Can’t see what or where i’m doing something wrong. I have another file where the roof if ok.
I believe the ‘average_floor_height’ room attribute is wrong. Instead of getting some height (3 for the example) i’m getting 0. Can be?
For point 2., the average_floor_height property probably should have been named average_floor_elevation. It’s the average Z value of the floor Faces of the Room. It’s not a floor_to_floor_height or floor_to_ceiling_height like you have in Dragonfly. In fact, such properties really don’t exist in Honeybee because not all Honeybee Rooms are extruded floor plates. However, you can get the difference in Z values between the min and the max of the bounding box around the Honeybee Room geometry like so:
The question of whether you should just have the component output Rooms with windows or just a list of glazing ratios is really up to you and what you see as the most common use case. If you think that you’ll be creating different patters of windows with the same ratio fairly often, then just outputting the ratios seems fine. It might take a little longer to generate the windows for large models as it looks like you’ll have to graft the rooms input to the “HB Apertures by Ratio”. But, if you need the control over window geometry, then it’s worth the tradeoff.
I am not sure what you’re asking in points 3 and 4 or what part of your code that you want me to check. If you have a question about how to get a specific attribute, like the difference in Z values above, then I can be a bit more helpful.
I just added a few more components and inputs to give you better control over boundary conditions on dragonfly objects:
Notably, you can now assign adiabatic and ground boundary conditions by orientation. This should make it easier to setup things like basements and parti walls on dragonfly. I also exposed an air_boundary_ input on the “DF Solve Adjacency” component that allows you to assign air boundaries from dragonfly.
would the same python script be possible to implement on the DF Building from solid from the Ladybug tools 1.4.0 release?
The idea is the same: to remove the windows from wall segments having less than a specified segment length. I tried using your code with the following report: “1. Solution exception:‘Building’ object has no attribute ‘window_parameters’”.
If it would work in theory, how should the code be modified?
That sample code is only meant to work from dragonfly Rooms. Not entire buildings. You can get the rooms of a building by means of the Building.unique_room_2ds property. So the code would work like this:
from ladybug_rhino.grasshopper import all_required_inputs
if all_required_inputs(ghenv.Component):
new_bldg = bldg.duplicate() # duplicate to avoid editing component input
room2ds = new_bldg.unique_room_2ds
for room in room2ds:
win_pars = list(room.window_parameters)
for i, seg in enumerate(room.floor_segments):
if seg.length < _seg_length:
win_pars[i] = None # remove any windows assigned to the segment
room.window_parameters = win_pars
