Grasshopper

algorithmic modeling for Rhino

Hi,

Question: Would it be correct to say that the VSC component calculation can also be interpreted as Sky View Factor?

Maybe it is the hour, but i'm getting confused here.

Thanks,

-A.

Views: 4571

Replies are closed for this discussion.

Replies to This Discussion

hello everybody!, I am quite sensitive to the topic as I would like to use more VSC in honeybee or ladybug as I am still using ecotect to calculate VSC because I "trust" results more.

Maybe this  could be of some help.

VSC is graphically calculated using the waldram diagram that divide the sky in showed in the image below.

I am quite sure that the 1-2% difference comes from calculating the portions of the sky in a different way so maybe this diagram might help you to  identify the right proportions to calculate vsc!

Thanks !

Amedeo

Abraham,

I forgot to mention here that you bug you reported was fixed a few days ago:

https://github.com/mostaphaRoudsari/ladybug/issues/229

Amadeo,

Thank you for posting your knowledge.  I am still a bit unclear on how the waldram diagram divides up the sky of if it is different from a Tregenza division of the sky.  However, I can tell you that running the new Ladybug view analysis component with a high skyResolution is likely to give you a more trustworthy result than an ecotect study with a low sky resolution.  For a sanity check about how the calculation is being run in Ladybug, you can always connect up a vector display to the new 'viewVec' output of the component:

By changing the slider, you can understand how the accuracy of the simulation improves with higher resolutions.

Hope this helps,

-Chris

Attachments:

Abraham,

I am just letting you know that I was able to re-create the discrepancy between the Ladybug SVF and Radiance VSC calculations with a simple case.

I also checked the results against the Sky Mask II component, which I think is the most trustworthy of all operations as long as we verify that the output shading mask geometry is correct.  In this validation, I got the following result:

Sky Mask II (Most trustworthy if checked) - 43.0423 %

View Analysis (SVF) - 41.277 %

Radiance VSC - 37.10 %

While the 1.8% error of the Ladybug view analysis component is acceptable for many of my applications, the almost 6% error on the Radiance calculation seems to be way outside the acceptable range.  Increasing the ambient divisions of the Radiance simulation did not help the issue.  As a result, I am considering taking out the Radiance VSC until we can better understand why the answer is so much lower than the others.

I should also note that all 3 methods were in agreement when I fed in spherical test cases with known solutions for svf.  It is just when we start introducing orthagonal geometry at lower svf that this discrepancy emerges.

Mostapha, what are your thoughts on taking out HB VSC for the time being or investigating the issue deeper?

-Chris

Attachments:

Ok, I think that I have finally gotten to the bottom of this!  All of the components are correct and there is apparently a subtle yet important difference between Sky View Factor and Vertical Sky component.  According to the glossary of the (admittedly somewhat old) reference of Sun, Wind and Light, there are separate definitions for the two metrics.  They are as follows:

Sky Component - The portion of the daylight factor (at a point indoors) contributed by luminance from the sky, excluding direct sunlight.

Sky View Factor - The sector of the sky as seen from a daylight aperture or building surface.  It can be measured as either a fraction or as a three-dimensional solid angle.

It seems that we all thought these metrics were the same but it turns out that Sky Component is just a weird (and almost deceptive) metric.  Frankly, I can't understand what it is used for.  However, perhaps the even more deceptive fact is that the Sky component computed with a uniform Radiance sky is not actually using a perfectly uniform sky as seen here.

So we will always get VSC results that are not aligned with that which we get from the sky view components.  All of this and the fact that sky component seems to be an outdated metric makes me want to take it out unless someone can give a good reason for how it could do more good than the harm that it has done here in deceiving us.

I still see important merit in keeping the sky view components as sky view is important for modelling the cooling down of surfaces at night as they radiate heat to the cool night sky.  Sky component just seems like an outdated daylight metric.

Let us know your thoughts and I have opened up a github issue for further discussion:

https://github.com/mostaphaRoudsari/ladybug/issues/230

-Chris

Hi Chris,

Thanks. I was aware of the update :-)

As for taking the HB_VSC out i won't do it. When Mostapha just released it we did  some intensive testing and found good agreement with the standards. See this and this (right now seemd to be a broken link but hopefully not). I believe the answer for my original question is that is not correct to use SVF for VSC and visceversa. They are close but not fully (see that VSC takes into account 2 sky conditions, uniform CIE and cloudy while SVF is clean of that).

BTW in your example i also added the LB_shadingMask and the agreement with the LB_shadingMaskII is completely equal (43.13% vs 43.04%).

-A.

Abraham,

Now that the purpose of all metrics has been clarified to me, I see good solid reasons for keeping and using the VSC component.  See this discussion for how all of this has all finally made sense to me:

http://www.grasshopper3d.com/group/ladybug/forum/topics/discussion-...

My only issue now is that we should probably be more technically correct and change the name of the component to simply be “Sky Component” instead of “Vertical Sky Component”.  This is because the Vertical Sky Component recipe for Honeybee might not always be evaluating VERTICAL sky.  The sky component might be vertical, horizontal, or in any direction that the input test surface is placed and ptsVectors are oriented.

Also, as for the uniform sky issue in my previous post, I realized that the slight change in falsecolor around the circle does not actually affect the results and is probably the result of tolerances close to the horizon.  I apologize for the false alarm.

-Chris

Hi Chris,

Agree that the VSC can be applied to any surface, and as a result of that the name change can be in order. But, just thinking/wondering, who will use this for any surface but vertical. This measurement is not giving any useful information for them. At least not what it was intended for. This as opposed to the SVF.

So instead of changing the name, and diluting the original purpose of the component, maybe a warning or an explanation showing the purpose of the analysis.

This is one of those situations that "just because it is possible to do" can be lead to conceptual mistakes.

What do you think?

-A.

Abraham,

I agree and see the sky view thread for all of my comments:

http://www.grasshopper3d.com/group/ladybug/forum/topics/discussion-...

-Chris

This is so great. This thread was (maybe still is) a very good one together with the other you linked. The best was to put them together.

What is interesting is that at the end of the process, and after your implementation, comes up that my original question was right, just with the updated component :-)

Thanks,

-A.

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service