Ladybug_Sunlight Hours Analysis geometry self-shading?

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

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Devang Chauhan on January 16, 2017 at 2:46pm

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

Permalink Reply by Francesco De Luca on January 17, 2017 at 1:58am

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

Permalink Reply by Abraham Yezioro on January 16, 2017 at 3:12pm

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.

Permalink Reply by Francesco De Luca on January 17, 2017 at 1:26am

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

Permalink Reply by Francesco De Luca on January 17, 2017 at 2:09am

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

Permalink Reply by Devang Chauhan on January 17, 2017 at 4:05am

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

Attachments:

Total Sunlight Hours.gh, 412 KB

Permalink Reply by Devang Chauhan on January 17, 2017 at 4:17am

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.

Permalink Reply by Francesco De Luca on January 17, 2017 at 4:35am

Devang,

then we have a mistery because I don't get the same result using the same procedure.

Look at my images. This is the analyzed box

this is the result

I see that you use a newer version Oct 31 of the 0.0.63 but I use the Aug 10.

But I think is not this the problem.

Anyway I don't really understand two things:

1 - what kind of measurement is this? You multiply the total sunlight hours by the surface area? This is not an average in my understanding, it look more like a total something. It would make more sense if you would divide the totals of sun light hours for the surface area, in this case it would be a sort of normalized quantity of sunlight hour per facade (h/m2).

2 - if it is not an average, then why the tooltip say "average"

Francesco

Permalink Reply by Devang Chauhan on January 17, 2017 at 6:47am

Francesco

We, the men of science don't like mysteries. Do we?

So the area that being multiplied is the area of all the faces that you get when you deconstruct the meshes coming out of analysisMesh output.

I have again attached the example demonstrating how the component is calculating the total Sun light hours. This should work at your end as well. For your other questions as to why this calculation is done this way, perhaps Mostapha can share his point of view.

Attachments:

Total Sunlight Hours.gh, 413 KB

Permalink Reply by Francesco De Luca on January 17, 2017 at 7:56am

Devang,

yes I understood the principle that you say is at the base of this calculation but

I don´t understand its validity. In this moment I cannot make any test but I think that if it works in that way then when you try different grid sizes (number of test points) the results will be different. Is it so? Is this a valid way to make studies?

When I mention the word "mystery" I didn´t mean how the component works, but why then I don´t get the same result using the calculation you say and from the output totalSunlightHours. I attach again the same image of my previous post if you missed it.

Yes probably we will receive clarifications soon.

Francesco

Permalink Reply by Devang Chauhan on January 17, 2017 at 8:25am

Did you check try the Gh file I attached in the last reply? With that file you should receive the same result. Alternatively, I could take a look at your file.

The question "Why this calculation was set up this way?" shall be best answered by Mostapha I think.

-Devang

Permalink Reply by Mostapha Sadeghipour Roudsari on January 17, 2017 at 6:27pm

1 - what kind of measurement is this? You multiply the total sunlight hours by the surface area? This is not an average in my understanding, it look more like a total something. It would make more sense if you would divide the totals of sun light hours for the surface area, in this case it would be a sort of normalized quantity of sunlight hour per facade (h/m2).

2 - if it is not an average, then why the tooltip say "average"

Francesco, You're right on both. The reason I picked area * number of hours, which is a nonsense as a value, over the average is that it let's you compare two design options against each other using a single value. The tooltip should get fixed.