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.
Abraham,
I like your idea of using VSC to calculate a Sky View Factor. Unfortunately, because VSC is affected by glazing properties and reflected light, the same sky view could result in different VSC values if the model material properties change.
If you removed all of your glass and calculated a single ray (ab-0) run under uniform sky conditions, that might work. I never use VSC, so I might be off here, but that sounds reasonable. What do you think?
-Leland
Thanks for the “support” Leland 
At least i see that someone else sees the logic behind the thinking.
VSC is the only DL component that doesn’t have a radParameters input. The ab setting for this calculation is set to 1, so one bounce is OK, no matter the properties of the materials (even mirror glazed).
So i think the component can be also used for SVF.
Judge Mostapha?
-A.
BTW,
The Shadingmask gives a point in space SVF, but having a map of this parameter is nicer and probably more useful for design/research purposes.
-A.
Abraham,
From the papers that I have read on urban heat island (where sky view is important for modeling the escape of long wave radiation from urban canyons to the sky at night), I had always understood skyview and VSC to be synonymous. Mostapha will hopefully help confirm this soon.
-Chris
Thanks Chris,
In the meantime i’ve been doing some tests with the Shadingmask component just to compare results with the VSC’s. So far no good correlation. The differences are pretty big, sometimes beyond 15-20%.
Being the SVF a completely geometrical calculation (no sky influence) i was hopping the results will be in the same order of numbers (also played with the resolution of the Shadingmask but no improvement). Makes me think that maybe the -ab = 1 in the VSC is the cause. So maybe for SVF this parameter should be set to 0, as Leland said …?
-A.
Hi all, The methodology for the component as mentioned in description is based on this Radiance post (http://www.radiance-online.org/pipermail/radiance-general/2006-Sept…). The post suggests ab=1 for some technical reasons but it’s not really convincing.
Abraham. Can you post results of your study? That might be helpful to understand what’s going on.
Here you go Mostapha.
You’ll get the map on the ground surface. There i plot the VSC results.
After that i check random points with the ShadingMask (manually).
-A.
06_CrossTower_V0+VSC_Internalise.gh (525 KB)
Hi Chris,
I’m checking the version of LB_viewAnalysis you released today. I see the option of SVF (great).
In the process the component gives an error (red component) regarding the viewPtsWeights missing (line 526). I solved it temporary changing the variable name for “1”. I see that this variable shows in some other places as a parameter but not as a variable influencing the calculations. So i assume it can be deleted from the component.
I’ll keep checking and will report results here.
Thanks,
-A.
OK. I’ve been checking a bit the viewAnalysis regarding the SVF.
The results vary a bit from those of the LB_shadingMask (1-2%), which a see a s good consistency. This is great. I can say that the VSC doesn’t show a good agreement with this SVF, so even though the logic can be similar they don’t converge.
For consistency between the viewAnalysis and shadingMask the viewResolution_ and the skyDensity inputs, accordingly, represent the same resolution value? The first part of the description says so, but just want to be sure. Maybe the input name can be similar (i assume that viewRessolution applies only to SVF analysis)?
Thanks,
-A.
Abraham,
The error was a bug that I have just fixed:
https://github.com/mostaphaRoudsari/ladybug/commit/de15d1dd2b5411ec…
Thank you, as always, for finding these issues before anyone else does.
The results with the view component should be equivalent to the LB_shadingMask as I am using the exact same method of projecting vectors to the center of the sky patches. The only thing that I can think might be causing the 1-2% discrepancy is that Mostapha might be accounting for the areas of the sky patches and I am just assuming that each sky patch is of equal area to the others. If anyone has any strong feeling about accounting for the areas of the sky patches, let me know and I can work it in. I know that Tregenza originally divided them that way to have as equal areas as possible so I thought that I might be safe with the assumption.
The skyDensity and viewResolution inputs are the same parameter from the perspective of the LB_LB component that generates the patches/vectors. I used the more general term “viewResolution” since I am using the evenly distributed vectors for other types of view analysis (like spherical view) and not just sky view.
How far off is the agreement with the VSC component? Radiance is going to use the stoichastic method, which is going to be different than projecting the same evenly distributed view vectors. If it’s really far from a high resolution view study, maybe we need to look into the HB_VSC code.
-Chris
Hi Chris,
The error was not fixed. I’m still having this:
Runtime error (UnboundNameException): name ‘viewPtsWeights_’ is not defined
Traceback:
line 531, in script
with the Jan 8 version. You left in line 531 the variable viewPtsWeights, which is not in the inputs anymore. For now i changed the code giving “1” instead the variable, so the component can run, but i know that viewPtsWeights shows in other places.
The differences with VSC go between 5 to 20% or more (depending if the sample point is more exposed to the sky). This is really far away.
I’m good with the other explanations.
Thanks,
-A.
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
viewVectorDisplay.gh (370 KB)
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
viewVectorTest.gh (475 KB)
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.
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
1 Like
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.