Odd results from the HB Direct Sun Hours

Hi team LB,

I’m recently working on a direct sun hour study for an apartment building, and the main objective of this study is to find out which window could not have access to direct sun light on a specific day.

And the HB Direct Sun Hour was used, and to validate the results, I drew the line between sensor points and the position of the sun at each time step (If there is no intersection with other surfaces that means the sensor points receive direct sun light). Then I compared the results from those two methods, and the results don’t match up (There are quite a few sensor points that can reach the sun without any obstruction by drawing the line between the sun and them, but the HB Direct Sun Hours component gave a completely opposite result). So, I am posting this to see if I can get some help from here.

I have attached a file below, please take a look.

DSH.gh (400.8 KB)

Thanks in advance,
Bernard

Your visual check [drawing the lines between window sensors and sun points] has a big flaw: hose lines are not vectors and they depend much on the scale of the sunpath and it’s center point.
See attached for what i suggest you to check: Each point needs to have it own sunpath (becouse of the center point) and then draw a vector from window sensors to sun positions.
Hope it is clear enough …
-A.
DSH_AY.gh (399.8 KB)

Thanks for the explanation, but with this change the result still doesn’t match up.

According to the visual check, those three vectors hightide in green can reach the sun without any obstruction. However, the results from the recipe shows the sensor can not have the direct sun.

And now I am suspect if this is related to the Radiance parameters such as -ad value. Since the Direct Sun Hours recipe can not customize the radiance parameters.

Do you know what could potentially cause this mismatch? Any insights would be appreciated!

Cheers,
Bernard

I didn’t check the way you calculate the values of the exposure. But i did notice that you set a possible binary result (either 0 or 1).
For the image you posted above what is the expected result when 3 rays hot the sun and 7 don’t? It is a 0 or a 1? Maybe a 0.3?
-A.

Sorry for the confusion, and blow is the further explains regarding the script.

Since the recipe return with 0/1 values, so I sum up the results during the entire study period, and if one sensor’s results is greater than 0 which represents the sun ray can hit the sensor during the simulated period.

And the image posted above, shows the 3 rays can reach the sun and it suppose to give me a true results from the recipe. But it gave me a false result instead.

Hi @zengwoo1028,

What happens if you use HB Wea From EPW to change the timestep of the Wea?

Hi Mikkel,

Thanks for the solution, and it perfectly solves the mismatch! And may I ask why this approach could solve the problem?

Thanks in advance,
Bernard

The _timestep_ input in the recipe is only used in the post-processing. It is the _wea input that really determines how many solar positions that will be evaluated.

If you do not change the timestep in the Wea, then it will run the simulation with timestep = 1, but the post-processing will run with timestep = 10. In this case you will get the results on the left (the red rows for every 10th timestep). If you change the timestep in the Wea you will get the results on the right.

I have roughly highlighted the period that you were looking at, and as you can see there are no red cells in inside the black border in the left image.

2 Likes

Super! and thank you very much for the crystal clear explanation :innocent:

Bernard