[Radiance-general] Annual illuminance simulation anomaly

[Thomas Bleicher]

Hi David.

I have played with gendaylit recently and also thought about the
problems it has.

On Wed, Mar 3, 2010 at 12:05 AM, David Smith <dbs176 at gmail.com> wrote:
> Dear Radiance gurus,
>
> I guess I have two actual questions out of all of this:
> A. If I wanted to get a Radiance scene description that would [best]
> match the climate, what are the best data to use as inputs?

Given the information available in data files and the input our
generators expect using radiation data seems to be a good choice. It
might be more accurate to use illuminance data instead and divide this
by Radiance's built in sky efficacy of 179. If you use irradiance and
solar radiance you imply that the sky has this same efficacy, which is
not true. However, illuminance data is not always available (EPW files
do have this information, other climate files do not).

BTW: I noticed in your plot that you labeled the gensky parameters as
"-B" and "-r". I think you have to use "-r" because the information in
the EPW file is direct _normal_ radiance not direct _horizontal_
irradiance. This might well be the cause of your odd spikes because
with "-R" you ask for a cosine correction which will be quite extreme
for low angles.

I hope someone can confirm this because I don't know too much about
the EPW file. I just found the units for the various radiation data.
Direct normal is given in Wh/m2. Does that mean we have to convert to
Wh/sr/m2 if we want to use it with "-r" or apply a cosine correction
if we want to use "-R"?

> B. Is gendaylit a prudent way forward instead of gensky CIE skies for
> this climate? What about other climates?

Gensky implements a number of sky models (uniform, overcast,
intermediate and clear). When you use gensky you will have to decide
which of the models you want to use. There is not much guidance on how
to do this. You could go by cloud cover and visibility if you have
that information.

Gendaylit does not need this information. It will calculate the
brightness distribution based on the radiation input which makes it
much easier to use in a script.

There are certainly sky conditions where neither of the models creates
an accurate description. Depending on the climate this might be true
for a large number of the records in the climate data file. However,
without an alternative you have to make a choice which of these models
you want to use and hope that over the whole year these errors have no
significant impact on the distribution.


> So, keeping those in mind, let's see if I can address some other
> people's questions:
> 1. I double checked everything and am quite certain I was picking the
> right columns (see test code below email).

Yep. Script seems fine.

> 3. I had never used gendaylit before, but gave that a chance. I'm
> unsure how to catch errors on the output though, so I ended up
> ignoring the errors (script assumes illuminance is 0 and outputs that
> instead).

Axel has used gendaylit with loads of climate data records recently
and came up with two basic error scenarios:

a) The direct component is 0. Some records refer to a time where the
sun is actually not visible and more. Gendaylit can't handle that and
so it will create no output at all. You can help yourself here by
adjusting the time as Andrew proposed until the sun is above the
horizon again.

b) Gendaylit simply segfaults. This seems to be rare. Perhaps cheating
with the values a bit might help (change by a few % or so) or simply
replace that sky with a gensky generated one which seems to be more
generous in what it accepts.

Still, it's worth validating the generated sky as you did in your
graphs to see how big the error actually is. That will give you an
idea of how accurate your simulation results are going to be.

Regards,
Thomas