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?
Mahsa,
I had never heard of ASE until you posted this question and I googled it. To be clear, is this what you are referring to:
Annual Sun Exposure (ASE) describes how much of space receives too much direct sunlight, which can cause visual discomfort (glare) or increase cooling loads. Specifically, ASE measures the percentage of floor area that receives at least 1000 lux for at least 250 occupied hours per year.
Normally, to account for glare potential over the whole year, I run studies with the Ladybug sunlight hours component and support my interpretation of it with simulations of daylight glare probability (DGP) using Honeybee glare analysis.
At first glance, I am a bit skeptical of this ASE metric. Is there any documentation on why they chose 1000 lux? It seems fairly arbitrary and not consistent with what I have heard from experts about minimum lightnlevels needed to experience glare (~4000 lux).
While I say that you should use this metric at your own risk, you can calculate it with the “Read Anual Daylight Result II” component and set the threshold at 1000 lux.
-Chris
I meant set the threshold to 1000 lux. That’s what I get for responding from my phone…
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
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.
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.
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
This is a very interesting discussion, especially with the upcoming LEED v4.
I will soon try some calculations of the sort, I actually did use Chris’s definition with very good results so far. However, I did not compare results to v4 criteria yet. In my specific region, I would think achieving ASE would be very easy due to very low direct illuminance, which makes it interesting for other people around the world to share any results they get on this.
I had a question on Alstan’s presentation. Is it a LEED requirement or a sensible thing to calculate sDA by compiling the 3 scenarios detailed there. Is this how the calculation is performed in HB as well? By combining shades open/close and ab=0? I must be getting that slide (8) wrong I guess.
Kind regards,
Theodore.
My two cents here…
sDA calculation and 2% rule are dictated by IES LM-83-12 and LEED v4 adopts sDA metric. Unlike DA or other annual metrics, blind operation should be embedded in sDA calculation. The aim is to prevent overestimating the amount of usable light or underestimating lighting energy consumption (Daylighting performance will be penalized when users will lower blind to prevent potential glare issue at certain period of time).
More details could be found at sDA and blinds operation
I have the same question whether HB can support sDA calculation.
Hi Cheney,
Currently Honeybee is using Daysim which unless you have only a single window in your room, or all the blinds go up and down together can’t model blind operations as suggested by IES LEM-83-12. Sarith is implementing Radiance’s 3-5 phase methods to Honeybee which will make the process possible.
Your best bet at this point is OpenStudio and using RadianceDaylight measure. Honeybee let’s you to export the model as osm and then you can use OpenStudio for the rest.
We also have an experimental workflow under development that let’s you run OpenStudio measures form inside Honeybee but it won’t work for daylighting measure for some OpenStudio limitations that you can read here and here.
Hi Mostapha,
Thanks for your clarification!
Actually I am using one room+ single window in HB for my parametric study which will help architects make design decision at initial design stage. Am I right to say, based on your reply, that it is still possible to follow IES LEM-83-12 to estimate sDA in HB? It would be great if you are able to show me any example or workaround.
For LEED v4 calculation, currently I am using Diva4Rhino. But I am very interested in the HB/OpenStudio workflow and expect to compare sDA/ASE results generated by different workflows. According to my current understanding, it is very difficult to achieve LEED v4 daylight points under option 1.
Thanks again for your prompt reply.
Regards, Cheney
Hi Cheney,
Yes. It’s possible to do it with Honeybee but there are technical issues with using Daysim for calculating ASE. Read Sarith comments here.
I can put an example together. You can use dynamic blind workflow and check the results for each hour but let me not do it until we have a Radiance-based workflow. Anytime that I have shared example files with caveats, even though I always clearly explained the limitations, I saw them being used by users without considering the limitations. Not everyone is knowledgeable as you.
Let us share the workflow with you once we have the Radiance based method ready :). Fortunately you have some alternative workflows for now to get it done.
Cheers,
Mostapha
There may be an alternative to using Radiance for the ASE calculations.
but since ASE doesnt need bounces of diffuse light, why don’t anyone use the SunPath’s SunVectors per hour and MeshRay or Occlusion to see, precisely, when different points in the grid are hit by the sun. I mean, in most cases, if there is direct sun, then it would be >1000 lux, if LT is not super low. As an extra, the solarIrradiation from the EPW file could tell what the direct-normal irradiation is.
If this could be set up in a multi thread workflow, it might be feasible ?
/bump
This is an interesting thread and upcoming release should add a lot of discussion to it.