Grasshopper

algorithmic modeling for Rhino

Dear bee and bugs,

I'd like to share and discuss with you my understanding of Sky View Factor, considering that it is an import concept frequently misunderstood.

Sky View Factor is first and foremost defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.

So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:

(image extracted from Johnson, G. T., & Watson, 1984)

Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:

So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.

The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.

H/W=0.25, SVF=0.895

H/W=1, SVF=0.447

H/W=2, SVF=0.246

It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)

According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.

I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.

Appreciate your comments and advice!

References:

  • SVF: definition based on first principle
  1. Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
  2. Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
  3. Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
  4. Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
  • Papers on SVF calculation:
  1. Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
  • SVF calculation based on first principle:
  1. Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
  • paper on Sky Exposure Factor:
  1. Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011

Views: 7447

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

This is an excellent write-up and literature review. Thank you !

Thanks a lot for your research Grasshope!

Hi Grasshope,

I'm sure Chris will get back to you soon here. I also just wanted to thank you for the great post. :)

Mostapha

Grasshope,

Thank you for assembling such an awesome set of research and publications.  It seems that we are finally getting to some conclusions about the differences between Sky View Factor (SVF), Vertical Sky Component (VSC), and now Sky Exposure Factor (SEF).  For everyone else following this post, this discussion has been ongoing in these other threads:

http://www.grasshopper3d.com/forum/topics/sky-view-factor-vs-vertic...

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

 

Grasshope, you have gone right to Oke, the grandfather of urban climatology, whose papers I have several times and yet I somehow I always missed the finer details of the sky view calculation.  From his definition, I had always thought of Sky View Factor as a purely solid angle or "view factor" calculation in the sense of Mean Radiant Temperature.  However, the numbers and formulas that you give here clearly show that Oke meant that this metric for quantifying and understanding urban heat island must refer back to the urban surfaces and their orientation in relation to the sky. It cannot simply be the view from points in space.

 

To clarify the distinction in simple geometric terms: The key difference is that Sky Exposure refers to the sky seen by a point in space while Sky View refers to that seen by a surface.  Both of them involve the calculation of either projected rays or solid angle calculations to the sky (since they both are “view” calculations).  However, while Sky Exposure treats each patch of the sky with relatively equal weight, Sky View weights these patches by their area after being projected into the plane of the surface being evaluated.  In other words, the sky view calculation for a horizontal surface would give more importance to the sky patches that are directly overhead than those near the horizon because these overhead patch are “in front” of the surface (as opposed to on the side).

To express this difference in the trigonometric terms you cite here:

Wall View = 0.5(sin2 θ + cos θ – 1) / (cos θ)

Wall Exposure = θ/π

I both cases:

θ = tan-1(H / 0.5W)   - ** This is the solid angle or ray-tracing calculation

SkyViewOrExposure = (1 - 2 (WallViewOrExposure))

 

To put this in more simpler terms for the View Analysis component, all that I actually have to do to convert sky exposure to sky view is multiply each of the traced view rays by 2cos(ϕ), where ϕ is the angle between the surface normal and the given view ray being traced.

I have done this by adding this line of code () and I have verified that I get the values from Oke’s paper that you cite above, Grasshope. Accordingly, the View Analysis component now has the option to compute either Sky Exposure or Sky View.  You can see this happening in this new example file:

http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&for...

 

To (once and for all!) clearly define the difference between the three metrics at the top of my reply and to explain how to calculate each with Ladybug Honeybee:

Sky Exposure Factor -  The percentage of the overlying hemispherical sky that is directly visible from a given POINT or set of POINTS.  This is equivalent to a geometric solid angle calculation or ray-tracing calculation from points.  It is useful for evaluating one's general visual connection to the sky at a given point and should be applied to cases where direct views to the sky are the parameter in question.

Sky exposure is calculated with the Ladybug_View Analysis component like so:

Sky View Factor – The percentage of the overlying hemispherical sky that is directly visible from a given SURFACE or set of SURFACES. While Sky Exposure treats each patch of the sky with relatively equal weight, Sky View weights these patches by their area projected into the plane of the surface being evaluated.  In other words, Sky View for a horizontal surface would give more importance to the sky patches that are overhead and less to those near the horizon.  Sky View is an important factor in for modelling urban heat island since the inability of warm urban surfaces to radiate heat to a cool night sky is one of the largest contributors of the heat island effect.

Sky View is calculates with either the Ladybug_View Analysis component like so:

Or with the Honeybee_Vertical Sky Component Recipe like so:

Sky Component - The portion of the daylight factor (at a surface indoors) contributed by luminance from the sky, excluding direct sunlight.  This is essentially the same as Sky View Factor but it often incorporates a sky condition that is not uniform, such as a cloudy sky or sky that is more indicative of diffuse sky light.  Another way of conceiving of this metric is a Daylight Factor calculation without any light bounces.  It is useful for understanding the direct daylight contribution of diffuse skylight and, although many consider it an older (and perhaps outdated) daylight metric, it is still required by some codes and standards.

Sky Component can be calculated with the Honeybee_Vertical Sky Component Recipe like so:

 

In addition to the added capability in the view analysis component, I have revised the component description to include the definitions above.  I have also corrected the Hydra example file in which I cite sky view as an urban heat island metric to use the new formula:

http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&for...

Finally, all of this discussion has made me realize that 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 pts vectors are oriented.  Accordingly, Mostapha, I think that we should change the name of the component to simply be “Sky Component” instead of “Vertical Sky Component”.  Please let me know if you agree.

 

Thanks again, Grasshope, for all of the great work!  All of this never would have made sense without your research.

-Chris

I forgot to point out the line of code that I changed in the view analsysis component - the empty parentheses () above:

https://github.com/mostaphaRoudsari/ladybug/blob/master/src/ladybug...

-Chris

This discussion is great.Thanks Grasshope and thanks Chris for wrapping things and implementing them.

But i think also that some other clarifications are in order.

The VSC (or Sky Component as Chris proposes now) definition is not quite right as stated above. From this link (sorry for that, but i'm lazy to look for a better one) we can see that:

The terms sky component and sky factor refer to the actual contribution of the sky to daylight, after considering both luminous distribution and incidence angle effects. There appear to be no hard and fast rules as to the type of sky distribution to be used with either term, however they are typically calculated using either the CIE Uniform Sky or CIE Overcast Sky to remove the dynamic effects of beam solar component.

After that the definition of VSc, as given by the BRE:

The Vertical Sky Component (VSC) is described by the UK Building Research Establishment (BRE) as the ratio of the direct sky illuminance falling on the vertical wall at a reference point, to the simultaneous horizontal illuminance under an unobstructed sky [Littlefair, 1991]. It also states that the Standard CIE Overcast Sky model is to be used for the sky illuminance distribution. This means that the reference value for the VSC percentage is effectively the unobstructed horizontal sky component.

And that's why i like a bit less the definition above (just sky component) and then generalizing the concept for all other possible surfaces.

As for SVF, doing a quick search of recent (relatively) sources that are trying to develop methodologies to define SVF they are based almost exclusively on solid/geometrical considerations. See these references for illustration:

Grimmond C.S.B., Potter S.K., Zutter H.N. and Souch C. 2001. Rapid Methods to Estimate Sky-View Factors Applied to Urban Areas. International Journal of Climatology. 21: 903–913 (2001). DOI: 10.1002/joc.659

Matuschek, O. Matzarakis, A. 2010. Estimation of Sky View Factor in Complex Environment as a Tool for Applied Climatological Studies. In: Matzarakis, A., Mayer, H., Chmielewski, F.-M. (Eds.), Proceedings of the 7th Conference on Biometeorology. Ber. Meteorol. Inst. Univ. Freiburg No. 20, 535-540.

Matzarakis A., Matuschek O. 2011. Sky view factor as a Parameter in Applied Climatology - Rapid Estimation by the Skyhelios Model. Meteorologische Zeitschrift, Vol. 20, No. 1, 039-045 (Open Access Article).

Hämmerle M., Gál T., UngerJ. & Matzarakis A. 2011. Comparison of Models Calculating the Sky View Factor Used for Urban Climate Investigations. Theoretical and Applied Climatology (2011) 105:521–527. DOI 10.1007/s00704-011-0402-3.

I know some other researches that use the term SVF just from its geometrical implications. This is probably because all those are based on site measurements or photographing.

It will be really interesting to calibrate those with the new LB component.

Thanks again,

-A.

Abraham,

I'm glad that we are finally coming to an agreement about what these terms refer to and that, at this point, we are just trying to define them in a clear manner so that others do not get as confused as we once were. Also, I agree that explaining what the components are intended to do is more helpful than explaining all of the possible things that you could do with the component.  So, to describe the two big areas of confusion that we want to clarify to new users:

The first is that we could use the Honeybee VSC component for urban heat island analyses to understand heat loss from surfaces of all orientations if we run it with a uniform sky (this would be just Sky Component without any 'Vertical').  However, I realize that having new users do this is potentially confusing if they have not gone through the same long process that we have or are approaching the VSC metric from its applications in day lighting and not urban heat island.  In fact, I remember Oke using the terms 'Sky Component' and 'Sky View Factor' interchangeably in a number of his papers (similar to your first definition, Abraham) and I think that this interchangeable use of terms might be partly to blame for my confusion over these past few discussions. Accordingly, I have revised the description of the Honeybee_VSC component to reflect this daylight-evaluating definition and I will leave the original name VSC for this reason.

https://github.com/mostaphaRoudsari/Honeybee/commit/755dc6c632398c8...

The second issue is that (as you also point out Abraham) some researchers do not differentiate between 'Sky View' and 'Sky Exposure'.  The example that I think you cite of people taking fish-eye images of the sky (a point-based method) and calling the visible portion of the sky sphere 'Sky View' is one that I have encountered a few times.  I also think that the Ecotect shading mask might not make this distinction and that the old Ladybug_Shading Mask also does not make this distinction.  However, I have just committed a new version of the shading mask component, which calculates both Sky Exposure and Sky View with a corresponding spherical or planar visual output that should help people understand the difference between the two.

https://github.com/mostaphaRoudsari/ladybug/commit/51a3a825ae394c48...

For the sake of clarity to new users, let me know if you agree with the following standard across Ladybug + Honeybee:

VSC should be used for daylight applications of exterior vertical walls (using the UK Building Research Establishment's definition) and calculated with the Honeybee_Vertical Sky Component recipe.

Sky View should be used for urban heat island applications, evaluating the heat loss of surfaces facing all different directions.  It should be calculated with the Ladybug_View Analysis component (or, if you only want to do a detailed analysis at a point, you can use the new Ladybug_Shading Mask component with the proper input).

Sky Exposure should be used to evaluate general visual connection of people to the sky and should be calculated with the the new Ladybug_Shading mask component that I just committed (or, if you need to test a series of points in a given region, the Ladybug_View Analysis might be helpful).

-Chris

It also occurred to me that I should include an example showing how to use the updated Shading Mask component and how I have validated against Grasshope's criteria at the top of the post.

Here, with a long street canyon with H/W of 0.5 you see:

Sky Exposure  = 50%

Sky View = 70%

To get these values to a higher accuracy with more decimal places, all that you have to do is increase the view resolution and the results eventually approach the number of decimal places given in Oke's paper.  I have moved the shading mask out of WIP now that we have validated it against this criteria and because it is useful for explaining the distinction that Grasshope makes at the top of the post between sky view and sky exposure.

-Chris

Attachments:

This is perfect Chris. Great work. Great discussion. Great outcome!!

-A.

To me this is a great example of the smart room. Very nice series of discussions.

"When an expert network is functioning as its best, the smartest person in the room is the room itself." - David Weinberger

I personally learned so much and will be more careful about using these terms.

Hi all,

Some additional points:

There is a direct relation between two View factors from two surfaces.

F1-2.A1=F2-1.A2

I think when one is using shadingmask or similar tool, it means that F1-2 is calculated from point to surfaces or sky then for F2-1 or SVF it needs to use the above equation.

SVF=F2-1=(A1/A2).F2-1 

- Other way to calculate SVF geometrically like NV method is to calculate

sum(2*Sin(Altitude))/n    which "n" is number of rays.

- Always be consider that the hotter surface radiant to the colder (Fh-c) so Sky temperature is one of the most important variable if you are calculating atmospheric long wave radiation or infrared. Furthermore, be careful about infrared bounces!! 

Navid

for more information for View factor:

http://www.thermalradiation.net/tablecon.html#C5

short youtube video:

https://www.youtube.com/watch?v=UIfRBB49MC4

Dear Chris and Abraham,

Apologize for my late reply!

Thank you very much for the discussion and detailed clarification from which the community will definitely learn a lot!

I agree with your differentiation between the three concepts, sky exposure, sky view factor and sky component, each of which defined in a particular rationale and having particular implications, and this may bring more clarity and precision to environmental performance analysis.

The revised view analysis component seems working well. I did a small test using a cylinder with its top open as the obstruction geometry and an upward test surface positioned at the centre of the bottom surface of the cylinder. By rotating the cylinder around the centroid of the test surface, we get different obstruction scenarios in relation to the test surface that have the same level of "sky exposure" but different "sky view factor", depending on the "relative position" of the visible sky to the normal of test surface as explained by Chris. The sky exposure factor value fluctuates a bit, but it is close to the value calculated according to trigonometry. (GH file attached)

I have one more small suggestion, if it's not too troublesome: it'll be great if the result legend text can change according to the type of view analysis specified automatically, instead of showing a general "Skyview Analysis".

Thank you all very much, again, for your great inputs and the swift update of the components!

Ji

Attachments:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service