Sky View Factor vs Vertical Sky Component

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.

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Leland Curtis on October 12, 2015 at 7:32am

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

Permalink Reply by Abraham Yezioro on October 12, 2015 at 8:18am

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.

Permalink Reply by Abraham Yezioro on October 13, 2015 at 9:44pm

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.

Permalink Reply by Chris Mackey on October 14, 2015 at 5:27am

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

Permalink Reply by Abraham Yezioro on October 14, 2015 at 11:53am

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.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 16, 2015 at 7:20am

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.

Permalink Reply by Abraham Yezioro on October 16, 2015 at 10:19am

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.

Attachments:

06_CrossTower_V0+VSC_Internalise.gh, 525 KB

Permalink Reply by Abraham Yezioro on January 5, 2016 at 10:09pm

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.

Permalink Reply by Abraham Yezioro on January 6, 2016 at 12:53am

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.

Permalink Reply by Chris Mackey on January 8, 2016 at 4:02pm

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

Permalink Reply by Abraham Yezioro on January 9, 2016 at 1:29am

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.

Permalink Reply by Abraham Yezioro on January 9, 2016 at 1:30am

I'm attaching the example i'm using for this case.

-A.

Attachments: