algorithmic modeling for Rhino
Hi
Thank you for your great program. I was wondering how to calculate the ASE with honeybee. I can get the grid based percentage of time over 1000 lux over the year but this is not exactly what ASE is, do you have any suggestions how it can be calculated using the honeybee components?
Tags:
Replies are closed for this discussion.
thank you for your relpy, Sda and ASE are the metrics implemented in LEED v4. There is a document on this
http://solemma.net/DIVADay/2014/11%20-%20DIVA%20Day%202014%20-%20LE...
https://www.ies.org/store/product/approved-method-ies-spatial-dayli...
Actually I tried to calculate it with the mentioned component but the problem is that it gives the percentage of time each node which is above 1000 lux but this is not ASE. I have to export the data into an excel sheet and calculate it manually. Mostapha had a post in previous discussions stating that" aSE calculation is a little bit tricky. I did partially implemented the calculation in the code but never exposed it as an output. I will try to post a discussion about the reasons behind this." I was wondering if he can explain more about this issue.
Mahsa
You have it all covered. One more limitation of Daysim is to model dynamic shadings for multiple windows. This is a very important limitation when it comes to calculating ASE accurately. The only accurate solution that I'm aware of for calculating ASE is Radiance's 3-Phase method. Also be careful about using annual DGP calculation with Daysim (https://github.com/mostaphaRoudsari/Honeybee/issues/243). In case you're using annual glare analysis make sure to double check the results by point in time glare analysis.
ASE, as described in IES LM 83-12, is supposed to be calculated considering direct sun contribution only. Which roughly translates to an -ab 0 (ie 0 bounce) calculation in Radiance/Daysim. It is assumed that a 1000 lux measurement for a particular hour on a workplane grid point will indicate a illuminance from direct sun at that point. If I remember correctly, these simulations are to be run without the presence of any shading devices.
From an ASE calculation perspective, there are several shortcomings within Daysim (as it exists right now). The daylight coefficient method, which Daysim employs, calculates illuminance by dividing the sky into discrete patches. (http://naturalfrequency.com/wiki/sky-subdivision) For a clear sky with sun, the luminance from sun is accounted for by approximating the position of sun into 3 (as far as I know) patches. That in turn leads to an incorrect estimation of both position and luminance contribution of the sun.
Anyways, as I wrote in the begining, in my opinion the closest you'd get to calculating ASE from daysim right now would be running an annual daylighting calculation with Honeybee by setting ambient bounces as zero. A better approach, in case you are not trying to comply with something like leed v4, would be to do a DGP analysis as Chris mentioned in his post.
Thank you very much Sarith for your useful comment. I think the best would be to change the metric to DGP.
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:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&for...
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,
-Chris
To add to Chris's comment about inclusion of ASE in LEED v4 being confusing, that opinion is actually shared by a fair number of daylighting experts.
Christoph Reinhart, whose research contributed to the creation of Daysim and DIVA, wrote an editorial about the daylighting metrics in LEED v4 where he raises similar concerns : http://lrt.sagepub.com/content/47/4/388.full.pdf+html
Dr. Reinhart, incidentally, is Alstan's dissertation advisor.
thank you Sarith for letting me know about Dr. Reinhart's technical note, it answers a lot of my questions regarding the validity of this metric.
thank you Chris and Mostapha for your detailed explanations and clarifications for the metric and how to calculate it. Thank you for your time and consideration it means a lot and was is a big help in my research.
I couldn't find a component to count values in GH but know this issue is solved. once again thank you for your great program and support
Bests
Mahsa
Also I found some useful information (Question and Answers) regarding this metric and it calculation on http://daylightmetrics.blogspot.com/
Hi Mahsa,
By using the current GH workflow, do you come across any successful case in which both sDA300lx,50% and ASE1000lx,250h below 10% can be fulfilled and LEED v4 credit could be achieved? Out of my curiosity, I desperately like to see a building which can fulfill LEED v4 requirement by balancing sDA and ASE successfully.
Regards,
Cheney
© 2019 Created by Scott Davidson. Powered by