Grasshopper

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?

Views: 3173

Replies are closed for this discussion.

Replies to This Discussion

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 100 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 thataSE 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 

   

RSS

About

Translate

Search

© 2018   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service