Inconsistencies in Shadebenefit evaluator

Replies to This Discussion

Permalink Reply by Chris Mackey on September 24, 2016 at 3:35pm

Aris,

Thanks for posting and your questions are good ones.  The way in which I made the shade benefit method relevant to thermal comfort has involved the creation of a fairly abstract metric of degree-days/square meter, which sometimes takes a while to understand.  To explain what is going on in the cases that you posted, I can tell you that the second one where you are just increasing the grid size is showing you that that there is actually greater variation in shade benefit when you zoom in and perform a calculation with more sun vectors.  This is why the legend increases (because there are some small spots that matter more when they are not averaged together with some less important spots).  If you multiply by the area of the individual cells in each case and add up all of the results for each of these two cases, you should get something similar as the absolute value provided by shading all of the beneficial regions.

The first case is a bit more difficult to explain but I am fairly certain that it is happening because each shade benefit simulation has a finite number of degree-days that it is trying to improve.  When you increase the size of the testRegion as you do in the first example, you are spreading those degree-days across a larger surface, resulting in overall smaller numbers of degree-days/m2.  One way that you might try to get a more constant metric (or more of an absolute value provided by the whole shade) is that you can multiply the results by the number of people that are seated in the testRegion (or perhaps just multiply by the area of the testRegion).  This way, you are accounting for the fact that the larger shade will make more people comfortable (it's not just one person or set of degree-days that you are improving).  In your specific case here, I think that we are also seeing a number of areas where the benefit of the shade is in conflict with the desire to not have shade in the winter, resulting in some smaller values.

Let me know if you end up testing out the multiplication by the testRegion area and, if you get results that indicate a more "absolute value" of the shade that is more consistent between the cases, I might consider revising the metric that is output from the component.  The important thing to realize across all of this is that the RELATIVE shade desirability across you testShade will always be the same (even if the way that we define absolute shade benefit changes).  So, if you have a finite amount of shade material, it is always in your interest to provide more of it in the areas with more shade desirability.

If you have more questions about how the component works, I can point you to this paper on it:

https://www.dropbox.com/s/cgrod252iopmci2/SIMAUD_Paper12.pdf?dl=0

Also, the original shade benefit method that this component is based on can be found here:

http://web.mit.edu/tito_/www/Publications/BS2011_Shaderade.pdf

Thanks again,

-Chris

Permalink Reply by Aris V on September 26, 2016 at 3:53am

Hi Chris

I followed your suggestions and did some more experiments. Multiplying the shadeneteffect values by the testregion area, as you have suggested, seems to yield more comparable results. I have attached the relevant gh definition to this post. You can see the result below:

Assuming that each person occupies a fixed amount of space, a multiplication by the number of people should generate similar results. However, the metric would get even more complex (DegreeDays*no. of people/m2 of shade). On the contrary, the multiplication by the test region area creates an even simpler metric (DegreeDays) which might be used to compare “levels of shading service (or disservice)” between different shaded areas.

As you already mention, the existing metric is not “wrong” and has its own uses, so you could either clarify this in the component description or add the new metric as an output.

Below you can see a comparison of two cases from the study site I am currently investigating. The site is a waterfront located in Crete with mostly northern, western and northwestern orientations, so the yearly shade harm is insignificant. The multiplication of shadebenefit by site area seems to provide a better interpretation of the shadow effect.

You can also observe that in the case of a west-facing site (case on the right) a horizontal shade has a smaller impact on thermal comfort (slightly lighter blue color) than southern/northern cases.

Best Regards

Aris

Attachments:

• Outdoor_Comfort_Shade_Benefit_2.gh, 473 KB

Permalink Reply by Chris Mackey on September 26, 2016 at 9:58am

Hi Aris,

Thanks so much for testing this. I buy the argument that multiplying the results by the test region area not only makes it easier to evaluate the total benefit of a shade but is also just a much cleaner metric (degree-days is much more intuitive than degree-days per m2).

I will change the output of the component soon and I have added a github issue for it here:
https://github.com/mostaphaRoudsari/ladybug/issues/296

Thanks again and very cool project,
-Chris

Permalink Reply by Chris Mackey on September 7, 2017 at 10:45am

Aris,

I apologize that this fell through the cracks for almost a year but I finally remembered to implement it:

https://github.com/mostaphaRoudsari/ladybug/commit/fe8fb38e97dd1551...

This is going to be much easier to explain to people now and I updated the description in the component as follows:

The units for shade desirability are degree-days, which are essentially the amount of time in days that sun is blocked by a given cell multiplied by the degrees above (or below) the _balanceTemperature during that time.  So, if a given square meter of _testShade has a shade desirability of 10 degree-days, this means that a shade in this location provides roughly 1 day of sun protection from conditions 10 degrees Celsius warmer than the balanceTemperature_ to 1 square meter of _testRegion.

Thanks again for suggesting this.

-Chris