I know this sounds like a question asked a million times and answered already, but…
I have been watching the nice videotutorials about daylight analysis and something is nagging me about the explanation of the CIE skies.
In the standard the local regulation codes refer to an “Overcast CIE” sky.
And in the tutorial a Climate based sky is referred to…
So here bubbles all the questions in my head:
1: An overcast sky is supposed to be directionless, right? Why does it need the loacation from the wheatherfile? Also the resulting .HDR image is not directionless. When tweaking the exposure in photoshop it clearly has a bright spot to the south (my location is in Norway).
2: A daylight factor analysis calculates the relationship between the exterior illuminated surface with an interior illuminated surface as a factor. So would it not be easier to just create an overcast sky with 10.000lux horisontal illumination and expect the interior surfaces to get more than 200lux?
Hope somebody more clever than I can tell enlighten me…
Yes, overcast sky as defined by CIE is supposed to be directionless i.e. the sky luminance does not vary in the z-axis (azimuth). The location info is needed for multiple reasons:
Radiance uses a single program (gensky) to generate all types of CIE skies. These include clear, intermediate and uniform skies. For a CIE overcast sky, even though the luminance gradient will remain uniform irrespective of location, the magnitude of luminance by itself depends on time and location data. I think the default values for longitude and latitude assigned to gensky correspond to those for Berkeley (or Oakland), California as that is where Radiance was developed in the mid 80s.
As far as I am aware, there are two grasshopper components in Honeybee that let you create CIE skies. Both these components invoke gensky to generate CIE sky definitions (code-snippet 1, code-snippet 2). The component that creates a uniform sky of certain illuminance level does not require location data, while the other component that creates several types of skies requires location data (for reasons that I pointed out above).
I think this is an issue specific to the simulation that you ran. Perhaps the ambient settings were off or there was reflected radiation. In my opinion, Photoshop isn’t a suitable arbiter of whether a Radiance-generated image had inconsistencies or not. It might be helpful to generate a couple of renderings of the outdoor context to see if the issue relay has to do with the sky.
Anyway, I was curious to test this out, so I ran a few quick simulations to check if there indeed was an azimuthal variability in the skies. Below is the reference image with the luminance scale, images that follow have the same scale.
The images below are for 9AM on 1st January for six different cities. The names of the cities, longitudes and latitudes are on the upper left of the images.
(The images above do not indicate any directional variability in the Z axis).
Yes. That will work too. You can use the uniform sky component for this and I guess the DF will be the same as what you get with the CIE overcast sky component.
A few years ago, Axel Jacobs wrote a brilliant article discussing the simplicity and usefulness of Daylight Factor while critiquing the complexity of climate-based daylight modeling (Page 15, the Climate Sceptic). Proponents of CBDM are several, most notably John Mardaljevic. You can find links to several of John’s writings on his webpage.
