Thanks for the clarification on the metric, Sarith, and for the link to Alstan’s presentation, Mahsa. The inclusion of 1000 lux in the definition of this metric seems incredibly confusing and distracting if its purpose is only meant to be a measure of direct beam sun. Still, given the history that LEED seems to have with selecting problematic daylight metrics that it later needs to revise (slide 2 of Alstan’s presentation), I guess I should not be so surprised at these issues are arising.
I see that, in Alstan’s presentation, he seems to be using Daysim to calculate ASE and, Sarith, you are right to bring up this issue that Daysim distributes the direct beam sun between 3-4 sky patches like so:
Mostapha should contribute when he gets the chance but I might imagine Daysim’s poor accounting for the position of the sun in the sky might be his grounds for not exposing it on his component. This said, I know that Alstan is a smart man and a daylight expert who I highly respect so I would have liked to have heard his thoughts on this process in his presentation.
In any case, for a more accurate means of observing where the sun is in the sky than Daysim’s method, you can use the Ladybug sunpath component and the corresponding sun vectors. So, if you want a means of calculating the percentage of the floor in direct beam sun over the year, you should use the sunlight hours component with the sun path and, if you want to exclude sun when it is very cloudy or low in the sky, you can use a conditional statement on the sun path to remove sun vectors when the outdoor global horizontal illuminance is below a certain threshold. For LEED, I guess that this threshold is 1000 lux multiplied by whatever the transmittance of your windows is but I would rather set it at 4000 lux since, as I said at the top of this post, I don’t know how IES or LEED arrived at this number and I at least know that 4000 lux is what the experts have agreed the upper limit of Useful Daylight Illuminance (UDI) should be. This workflow with the sunPath is similar to what I do in my office to account for glare, although I also add in an extra step to account for the fact that the hourly EPW data can add in an East-West bias (since illuminance values are recorded at the end of each hour as opposed to the start). I also put the results in terms of “hours of a typical 24-hour day” since it seems many people have a hard time understanding “hours of the year” intuitively. Finally, I use these sunlight hours to make a temporal map showing when the glare is likely to occur. I have found a good correlation between the presence of direct beam sun shining on the floor in these studies (even in small amounts) and Daylight Glare Probability (DGP) values above 0.4 (perceptible glare) for views looking towards the window or towards the floor by the window.
Here is an example file showing you how to do this calculation with the sunpath for yourself:
Also, Mahsa, there is usually no need to use excel when you have the data in GH. GH provides you with native math components that essentially have all of the capabilities of Excel (see the example file above).
Hope this helps,