Perez Sky for Daylight Simulation

radiance-general
1

Dear Mr.Ward,

I am student of architecture working an a daylight simulation with
radiance, still dealing with several problems.
I want to generate indoor illuminance values in Lux for a validation
with measured values of an office room.
I am working with the Perez all-weather skymodell in oder to
calculate with a sky which is equivalent to the measured outdoor
conditions.
For input in gendaylit I use the measured direct-normal and diffuse-
horizontal- illuminance [W/m�].

# gendaylit 1 11 12.00 -a 51.30 -o -7.28 -m -15 +s -W 154 93
# Ground ambient level: 11.1

void light solar
0
0
3 9.684e+005 9.684e+005 9.684e+005

solar source sun
0
0
4 0.156133 -0.946576 0.282165 0.533000

void brightfunc skyfunc
2 skybright perezlum.cal
0
10 2.411e+001 3.396e+000 -1.254300 -0.605648 10.900086 -
3.202346 0.012553 0.156133 -0.946576 0.282165

Then I add the sky description from gensky by preparing the octree

skyfunc glow sky_glow
0
0
4 1 1 1 0
sky_glow source sky
0
0
4 0 0 1 180

rtrace is running with the option -I and the following parameters
-ab 4 -av 0.10 0.10 0.10 -ds 0.15 -aa 0.15 -ad 512 -ar 128 -as 256 -
dc 0.50
-dj 0.7 -dp 512 -dr 3 -dt 0.05 -lr 8 -lw 0.002 -sj 1 -st 0.15

To obtain results for illuminance I execute rcalc for the coordinates
of the real measured points using a function I found in the mailing
archive

rcalc -e '$1=47.435*$1+119.93*$2+11.635*$3'

Unfortunatly I don't obtain reasonable results, neither for clear sky
nor for overcast conditions.
The generated values for the outdoor illuminance at clear sky
conditions are approximately 25% lower and at overcast
conditions 40 % higher than in reality.
The generated values for the outdoor illuminance are converse and
also definitive non equivalent in their progression.

It would be kind if You could help me.

Regards, Jorg Escher

University of Dortmund
Chair for Environmental Architecture
0049.231.755.54.25
[email protected]

2

Hello Jorg,

Not knowing anything about your model, it is difficult to say what might be the source of your error. There are so many possibilities, it's difficult to even count them. First off, you should include a ground description in your sky description, like so:

skyfunc glow sky_glow
0
4 1 1 1 0
sky_glow source sky
0
4 0 0 1 180
skyfunc glow ground_glow
0
4 1 1 1 0
ground_glow source ground
0
4 0 0 -1 180

Or, you could simply increase the coverage of your sky by changing the 180 to 360. The result will be the same. The reason it's important to include the ground glow is so that rays outside of your ground plane are not counted as black. I assume your model includes a ground plane (a large ring or polygon). If it does not, and your window is near to the ground such that the shadow of the building is important, it can make a significant difference to your results.

If you haven't done so already, I strongly recommend you read the chapter in "Rendering with Radiance" authored by John Mardaljevic, which goes into some detail regarding daylight simulations. His thesis is an even better reference, if you can get a copy. I didn't see a link to it on his website, but there are lots of other useful references there:

  http://www.iesd.dmu.ac.uk/~jm/

I do not have personal experience with the Perez model of gendaylit, but I can tell you from the experience I do have that real skies almost never match simulated ones. Unless you start from full angular measurements of your sky distribution, you cannot really hope for agreements between measurments and simulations of much better than +/-25%. This is not the fault of Radiance or of the options you give to the simulation, but simply a "reflection" of the difficulty of modeling something as naturally variable as skylight. Sky distribution models are designed to provide a basis for comparison between designs under "typical" sky conditions, and are ill-suited to matching specific skies or physical measurments. Try taking the same reading two days in a row under what you consider to be an overcast sky. I wouldn't be surprised if the ratio you measure between the outdoor and indoor illuminances doesn't vary under different real skies by at least 10-15%. You can't ask any simulation to get errors below this variation no matter how good it is or how well you have modeled the sky. To match the reality of a particular sky, you must measure it.

I hope this is helpful.
-Greg

3

[email protected] wrote:

I want to generate indoor illuminance values in Lux for a validation
with measured values of an office room.

Hi Joerg,

I don't wanna discourage you, but you're in for some MAJOR headaches.
Physical validations are a formidable task, to say the least. Errors are
numerous and unavoidable, and you'll have to figure out where they come
from and isolate them.

We've done a physical validation of the RADIANCE photon map at
Fraunhofer ISE, and I'm still trying to figure out some of the errors in
some instances. We kept everything as simple as possible. Even then,
it's still a nightmare.

We didn't even bother with daylight because of its fluctuations, but
used an artificial source instead. We also gave up using "real" daylight
systems in the measurements after we discovered that most of them have
defects (warping, etc) which vastly affect the light redirection and are
difficult to model. Furthermore, some systems may even give rise to
polarising effects, which cannot be modeled with RADIANCE. In the end,
we resorted to measurements with a simple light shelf.

To obtain results for illuminance I execute rcalc for the coordinates
of the real measured points using a function I found in the mailing
archive

rcalc -e '$1=47.435*$1+119.93*$2+11.635*$3'

I assume you're converting irradiance to illuminance here. You can of
course use your measured sky illuminance directly in the simulation
without the need for conversion -- RADIANCE won't care whether it
calculates in watts or lumens.

Beware that spectral effects can introduce some deviation if you treat
the walls as monochromatic in the simulation. You could roughly estimate
how much the daylight spectrum is modified by wall interreflection
before V(lambda) weighting by the sensors, which I assume is the case in
your setup.

Your validation is also complicated by the wall paint in your office.
Wall paint tends to be off-specular and in some cases even
retroreflective. RADIANCE's gaussian BRDF model will NOT account for
these effects. I suspect the paint's specular component (and no paint is
truly lambertian) contributes significantly to your error.

Unfortunatly I don't obtain reasonable results

Welcome to the club! :^)

Like I said, you're in for a VERY tough treat here. Life sucks when
comparing SimLife[tm] to RealLife[tm]. Good luck!!!

--Roland

···

--
END OF LINE. (MCP)

4

Greg Ward wrote:

If you haven't done so already, I strongly recommend you read the
chapter in "Rendering with Radiance" authored by John Mardaljevic,
which goes into some detail regarding daylight simulations. His thesis
is an even better reference, if you can get a copy. I didn't see a
link to it on his website, but there are lots of other useful
references there:

        http://www.iesd.dmu.ac.uk/~jm/

I obtained a PDF of John's thesis online. Infact, I'm pretty sure it was
available from his website, but maybe that's changed now. Anyway, if
Joerg can't find it, I've got it.

Other than that, I really can't think of any useful validation
references either. My eggs-perience[tm] was that, once you're in
RealLife[tm] territory... you're on your own, mate! There is no compass,
and don't rely on your intuition either. I chucked mine overboard early
on when I embarked on this voyage.

--Roland

···

--
END OF LINE. (MCP)