[Radiance-general] Sunlight hours calculation in radiance

[Reinhart, Christoph]

For those of you using Daysim, there is a fast subprogram called
gen_directsunlight that you can use for this purpose. The program places
your  scene in a glowing sphere and  then shoot rays from your work
plane sensor towards the direction of the sun if the direct radiation
component is above 50WM/m2 (according to the annual climate file). The
resulting *.dir file reports a "1" if direct sunlight hits the sensor
and '0' otherwise for every hour in the year.

 

Christoph

 

From: Thomas Bleicher [mailto:tbleicher at googlemail.com] 
Sent: Tuesday, February 15, 2011 10:02 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] Sunlight hours calculation in radiance

 

On Tue, Feb 15, 2011 at 7:28 AM, Giovanni Betti
<gbetti at fosterandpartners.com> wrote:

 

	I would be interested as well in seeing how other people
approached the
	same problem though.

 

In the UK you have to calculate sunlight hours on the ground for
planning purposes. 

 

We used a grid (as opposed to an image) and traced rays from each grid
point to the sun (direction was calculated from the gensky sun angle
information). We modified the rtrace command to print the material of
the surface it hits instead of the radiance. If the ray hits the sky (or
nothing) it returns "*", if it hits an obstruction it returns the
material name. Then you just need to count the "*"s in the output file
to know your number of sunlight hours.

 

For planning this is done on one day only, so we ran it with a 5 minute
resolution. It only took minutes for a reasonably sized grid and that
included all the preparation and evaluation in Lua (Ecotect). This
method generates a data array (x,y,n) which you have to visualise in a
separate step.

 

[On second thought you can probably combine this method with an vwrays
based preprocess to find all the surface points in the scene. For these
scene points you then evaluate the number of sunlight hours as above and
return the number as value for the image. Sounds like a longish
simulation, though.]

 

If you want pictures your idea with rtcontrib and optimised suns seems
very promising. A Tregenza subdivision is not optimal because the sun
only occupies about a quarter to a third of the sky. But you can run
rtcontrib on defined light sources so you just need to give all your
suns a unique identifier and you're set (the command line length might
be somewhat excessive, though). You can also interpolate between the sun
positions without loosing too much accuracy so you really only need to
evaluate a few hundred positions. It might be worth to split the summer
from the winter.

 

If you want to read the sun light hours directly from the final image
you have to use a unified sun source and combine all the images with a
cosine corrected intensity for this particular surface which results in
a 1 for each bright pixel on that surface. The final image gives you a
direct representation of the sunlight hours. If you have more than one
surface (more than one surface orientation, that is) you should go with
Lars' recommendation and apply a threshold value to convert all bright
pixels to a 1 value, regardless of the intensity.

 

Regards,

Thomas

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20110215/a14b8871/attachment.html>