Ladybug_Sunlight Hours Analysis geometry self-shading?

grasshopper ladybug-legacy
1

Hello,

using the component Ladybug_Sunlight Hours Analysis there are two inputs:

  • geometry (Geometry for which sunlight hours analysis will be conducted)

  • context (Context geometry that could block sunlight to the test geometry)

During some recent tests the results I get are very strange, it looks like the geometry objects are self-shading (i.e. I have a group of buildings surrounding two buildings if I analyse the two buildings separately the result is different than if I analyse the two buildings together). Is it like that? I always thought it was not and that if you wanted to use a “geometry” also as “context” you should have feed that in both inputs. Or something is changed in recent version of LB?

Thank you.

Francesco

2

Hi Francesco,

I see what you’re talking about. Please make a note that legend changes too when you add the second building. The legend is getting chagend due to change in High Bound and Low Bound values. These values will be different in the case of one building and in the case of two buildings. I believe, that’s the reason why you have that difference in visualization output.

-Devang

3

Hello Devang,

thank you for your reply. Actually is not that the problem. I am not using the legend to read the number of direct sun light hours on each building.

I explain a bit more what I am doing. What I need to know is the minimum number of direct sun light hours per day (during the specified period) per test-point/facade/building. so I made a small algorithm to check if each test-point get more or less of a specific amount of direct sun light hours per day in the specified period.

I want to test one building alone surrounded by different buildings (context) in different configurations and orientations. So when I say that I have two (ore more) buildings surrounded by other buildings I mean I have different configurations of the same building that I want to test with just one single run of the Ladybug_Sunlight Hours Analysis component so to have the work done more quickly.

So the problem is just that if I test each building configuration (in the geometry input) each time I get a result if I use multiple buildings (in the geometry input) I have another result. But that should not be. And I am sure in previous versions of Ladybug different geometries were not shadowing each-other until you input them also in the context input.

Best,

Francesco

4

Hi Francesco,

Thanks for elaborating. I understand your challenge now. I don’t know since how long it has been there, but as a matter of fact, Brep.JoinBreps Method is being applied to the list of breps that one supplied to the _geometry input.

So, when you supply different variations of your building, they are being joined in one Brep for analysis, and I know you already have figured this now.

A very quick option I think about right now is to use multiple sunlight hours components. I will still look further to find a more elegant solution.

-Devang

5

Hi Francesco,

For as long as I can remember, the sunlight hours component has always been like that. As has the radiation analysis component and the view analysis component (although I recently added in a _gemetryBlockView input). Perhaps you are thinking back to a time when Ladybug was less than 6 months old?

In any case, you can get around this issue by grafting your input _geometry so that each building is on its own branch. This will have the component run two separate sunlight hours studies for each branch (or building) instead of one combined study.I would strongly recommend this over your multiple components strategy, Devang, although you are onto the right solution. Generally, any time that you feel the urge to copy/paste a component, you should first consider trying to graft an input instead. This will keep your canvass much cleaner.

-Chris

6

Hi Chris,

Point noted. Thank you.

7

Thank you Devang for the suggestion and Chris for the clarification. Actually I solved, or better say I walked around, the issue in a bit tricky way, I created a loop that at each iteration is feeding the Ladybug_Sunlight Hours Analysis component with a different object variation and I am saving the results in a single list with a different branch for every iteration. So yes very tricky.

@ Chris Actually what I knew is that if you want an object to be a geometry and context at the same time you had to input it in both inputs, so this made me think that an object only in the geometry input would not act like context for another object in geometry. Maybe these information are from when LB was less than 6 months old but cannot say.

Thank you very much for the suggestion about grafting, actually sounds very logical but also this point “brakes” another belief I had about Ladybug_Sunlight Hours Analysis. I understood that it was not possible at all graft the input of geometry, even if I never investigated why, or the component would have not worked properly (this is why it come with the input flattened by default).

Ok then, I will give a try grafting the input geometry.

Best,

Francesco

8

Francesco,

Just to clarify that if you input an object as Geometry it also acts as context. So no need to input it twice.

-A.

9

Yes it is clear now, but can this be something you implement in the Ladybug_Sunlight Hours Analysis? I think could be useful that you can decide if an object is only geometry and not context until you don’t input it in the context input.

@ Chris I tried to graft the geometry input to get separate studies but I think is not working. As you can see from the images I have two buildings (dark grey) that are the same building in different locations, surrounded by other buildings (context). If I graft the geometry input I get six branches, the six sides of each box. It means that in each branch the results of the two boxes are merged, in factt if you see the results of the single building the number of test points is exacly the same. I tried also not with the copy of the same box but with two different and the result is the same. Or do I miss to do something?

Ok I could split each branch in two sub-branch {0;} and {1;} then I should separate the six branches of one box and the six brances of the other box… quite tricky.

If it is possible would be good that it works like I mentioned, that until you don’t input the same object in geometry and in context, but you input only in geometry it acts only as geometry so no need to deal with complicated lists.

I say this because the reseach I work on requires the calculations of minimum sunlight hours for each day (of the specified period) for each test point so it gets really complicated. Thank you!

Francesco

10

I read through the discussions but couldn’t really understand the issue. Just a comment about the geometry vs context for the future reference. Ladybug always runs self-intersections for test geometries. In other words, you should not connect the test geometries to context, and it has been the same from the first release of Ladybug.

11

Hi Francesco,

I tried grafting myself. It seems to work. please find my sample attached.

-Devang

Sunlight Hours Study.gh (421 KB)

12

Mostapha, I try to explain better.

I remembered (or I understood) that when you input more than one object in the geometry input they were ignoring each other so you could have made more studies, one for each object, with one single run, with each object surrounded by the same context geometries (if you check the image I attached the two dark grey boxes are the test geometries and the wirework boxes are the context).

Just recently I understood that it doesn’t work (I thought anymore) like this but that if you input more than one test object in the geometry input each one acts as context for the others. This makes things longer because it means that if I have to test say 100 variations of the same object I have to connect and disconnect the geometries 100 times. In the way I remember it was before I had just to input the 100 objects in the geometry input and with one single run get the results in different branches.

Chris says it always worked like this (that each test geometry acts as context for the others), so it means I misunderstood or more likely I remember wrong. So to run multiple studies at the same time he suggests to input multiple geometries and graft the input. I tried but the result is shown in the previous post, the output is quite complicated to manage. You can see that for two test objects with 6 sides each I get one single list with six branches.

Now is not important if it was always like that or was not, but I was suggesting that could be useful that it would work like I remember :slight_smile: if it is possible. When you input multiple test obejcts in the geometry input they ignore each other so you can run easily multiple studies, one for each object, at the same time. If you want to run one single study on two objects at the same time then you input also these objects in the context input so they shadow each other.

Let me know if this time was more clear. Thank you.

Francesco

13

Hello Devang, thank you for the effort.

But it is quite obvious that if you consider the totals then both buildings together or the sum of the results of the single building are the same. Things get much more complicated when you have to consider the result on each test point of each building, as I was trying to explain in my post.

Anyway in your definition there is somethig strange: 1) at a very quick glance I think that all the 4 results should be the same 2) I think it is not possible that you have a result of sun light hours that is not an integer

Francesco

14

Francesco,

Yes. When we provide multiple breps as geometries, the test points generated per brep differ in some cases and that indeed makes it tricky. So now I understand that grafting will not be a big help to you in this case.

The totalSunlightHours is actually sunlight hours multiplied by mesharea. That is why it’s not an integer. That is also the reason why those four numbers can not be the same.

-Devang

15

Francesco,

Depending on the type of result you want (Just the final number of hours, mesh and number of hours) i would explore using the StreamFilter component where each input is the geometry you want to calculate, run it with the Fly component and for each simulation record the results with the DataRecorder component.

Didn’t test but i think this can help somehow.

-A.

16

Abraham,

thank you, I think your suggestion works (and I used something similar) but only in the case you already have all the different object variation you want to test.

In my case I don’t have, so I tell you what I had to do and how I did it.

I have the following situation. A urban context with a square plot 40m x 40m surrounded by buildings.

If I extrude the plot I get 4 surfaces and I need to calculate the minimum daily quantity of direct sunlight hours each test point receives in the period from 22nd of April to 22nd of August. For example for the test point at index 21 of surface with index 1 (I am just creating these numbers in my mind) the minimum is on 27th of April and the test point receive 8 hours (this is also invented for the sake of the example) of direct sunlight. All the other days it receives more. So the values I have to found are these minimums for all the test points. Now how to calculate these minimum quantities is a different issue of the topic of this post and actually I manage it.

Continuing with the explanation of what I had to… so I have only the initial plot that generate 4 surfaces, then I want to test smaller plots generated by an offset of 4 m of the original one, and the relative 4 surfaces for each smaller plot.

So in this case I think I cannot use your suggestion because the object don’t exist yet.

I managed creating a loop with Anemone, the loop generate an offset starting from the original at 0 until 4 (then I multiply it by 4 to obtain the offset at 0, 4, 8, 12 and 16. Then I did like you also suggest I record every time the result with the DataRecorder and I create for each result a different branch with the index coming from the loop (0, 1, 2, 3 and 4) with the Flatten component.

In this image you can see all the surfaces saved in the same way as described above and in white the test points that receive minmum or equal than 2.5 hours per day of direct sunlight in the period from from 22nd of April to 22nd of August and in dark gray the test points that receive less.

The main point of this discussion is just the fact that instead use this tricky way I used, or the one you suggest, to analyze separately (because they shade each other) 20 geometries (in this case 20 they could be many more) it would be good if it would be possible just to input all the geometries at the same time and they would not shade each other so to get directly all the results with one run and in a more simple way.

Francesco

17

Devang,

thank you for indicating me this thing. Actually (also in this case) I remembered in a different way but now I see that the tooltip says:

totalSunlightHours

The average number of hours of direct sunlight received by the test _geometry.

So it doesn’t mention the surface area of the meshes. Are you sure about what you say? I am making a new comment to ask about this.

Francesco

18

Hello all,

from this discussion I am learning new things but I need clarifications.

I realize now (thanks to Devang) that in the component Ladybug_Sunlight Hours Analysis the output totalSunlightHours is “The average number of hours of direct sunlight received by the test _geometry.” as the tooltip says. Actually I remember that this was just the sum of all the sunlight hours of each node, wasn’t it? If it was not thenI am really getting old and my memory with me:)

But ok then, if it is the average then:

1 - why it is still called “total” and not “average”?

2 - can you please explain me these results?

I have these two same geometries to test (the dark grey boxes) and the surrounding context.

These are the results

Should not then the result 2 and 3 be the same?

Thank you.

Francesco

19

Hi Francesco,

Please check the following. This study is run on a 10m X 10m x 10m box with gride size of 10 meters. The sample file is attached too.

-Devang

Total Sunlight Hours.gh (412 KB)

20

This discussion nowhere near to an end. But, I have to say, I really appreciate the rigorous inquiry and follow-up by you. This is precisely why I love this community. Thank you very much for all your questions and elaborate description of the question you are dealing with.