Firstly I would like to express my gratitude for providing such amazing climatic design tools to the community. Keep up the great work!
In the last days I have been experimenting with the shade benefit evaluator tool, trying to determine the general shape of horizontal outdoor shades in various places of a waterfront.
I have noticed that although the tool seems to suggest correct shading forms, the numerical results (degree-days per sq.m.) are not easily comparable between different cases and this may cause misinterpretations. I did a few experiments using the Hydra example and examined only the shade helpfulness to make things less complicated.
While keeping all grasshopper parameters the same (including grid size = 1m) I changed the geometry of the potential shade and the area to be shaded. It can be observed that as the examined area becomes larger, the relative contribution of each shading patch becomes less significant. This is expected since the method calculates the percentage of the sun blocked as the component description states. Yet, the comparison of the calculated metric (degree-days/sq m) can easily lead to the assumption that the larger shade is less efficient than the smaller in terms of thermal comfort (1 degree-day/sq m vs 12 degree days/sq m), which is not true.
The same problem can also be observed when changing the resolution of the analysis to finer levels (e.g. 0.5m or 0.25m) while keeping geometry the same, although according to the component description, normalisation should take care of that (see fig. below).
Is this normal? Is there a work-around to this issue (e.g. a different metric or post-process procedure)? I would appreciate hearing your thoughts on this.
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:
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.
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:
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.
