Annual illuminance simulation anomaly

Dear list,

I was beginning an attempt to look at annual illuminance using the
information in a weather file (Energy Plus). As an initial test, I
used gensky while providing explicitly the direct normal radiation and
diffuse horizontal radiation from the weather file.
There was no actual geometry in the scene, just the sun, sky, skyglow,
etc. I then tested the illuminance with rtrace -I for a sensor
directed in the +Z direction as well as looking directly at the sun
where ever it was at that time.

What I found was that at the end of the day, the sensor point directly
facing the sun spikes dramatically. I've tried it with two different
weather files with similar results. Also, other sensor points pointed
in the general direction of the sunset spike correspondingly.

Here are links to two images, each showing the hourly averages for the
month of June:

Abu Dhabi: http://i49.tinypic.com/cnuhw.png
New York: http://i47.tinypic.com/20gz991.png

Does anybody have any insight to what may be causing this?

Cheers,

--Dave

Hi David,

In the case of "cnuhw.png," it looks like you are specifying a horizontal irradiance due to direct solar that is pretty high all the way to sunset. Since the direct horizontal is proportional to the sine of the solar altitude, and this goes to zero as the sun nears the horizon, the corresponding radiance of the sun has to increase dramatically to compensate.

A more realistic scenario would have the direct horizontal component dropping to zero as the sun reaches the horizon. My guess is that your weather files aren't calibrated properly to the hour, or their direct measurements actually include a significant diffuse component.

Does anyone else have experience with this?

Cheers,
-Greg

···

From: David Smith <[email protected]>
Date: February 26, 2010 3:47:52 PM PST

Dear list,

I was beginning an attempt to look at annual illuminance using the
information in a weather file (Energy Plus). As an initial test, I
used gensky while providing explicitly the direct normal radiation and
diffuse horizontal radiation from the weather file.
There was no actual geometry in the scene, just the sun, sky, skyglow,
etc. I then tested the illuminance with rtrace -I for a sensor
directed in the +Z direction as well as looking directly at the sun
where ever it was at that time.

What I found was that at the end of the day, the sensor point directly
facing the sun spikes dramatically. I've tried it with two different
weather files with similar results. Also, other sensor points pointed
in the general direction of the sunset spike correspondingly.

Here are links to two images, each showing the hourly averages for the
month of June:

Abu Dhabi: http://i49.tinypic.com/cnuhw.png
New York: http://i47.tinypic.com/20gz991.png

Does anybody have any insight to what may be causing this?

Cheers,

--Dave

Hi David,

In the case of "cnuhw.png," it looks like you are specifying a
horizontal irradiance due to direct solar that is pretty high all the
way to sunset. Since the direct horizontal is proportional to the
sine of the solar altitude, and this goes to zero as the sun nears the
horizon, the corresponding radiance of the sun has to increase
dramatically to compensate.

A more realistic scenario would have the direct horizontal component
dropping to zero as the sun reaches the horizon. My guess is that
your weather files aren't calibrated properly to the hour, or their
direct measurements actually include a significant diffuse component.

I was beginning an attempt to look at annual illuminance using the
information in a weather file (Energy Plus). As an initial test, I
used gensky while providing explicitly the direct normal radiation and
diffuse horizontal radiation from the weather file.
There was no actual geometry in the scene, just the sun, sky, skyglow,
etc. I then tested the illuminance with rtrace -I for a sensor
directed in the +Z direction as well as looking directly at the sun
where ever it was at that time.

What I found was that at the end of the day, the sensor point directly
facing the sun spikes dramatically. I've tried it with two different
weather files with similar results. Also, other sensor points pointed
in the general direction of the sunset spike correspondingly.

Here are links to two images, each showing the hourly averages for the
month of June:

Abu Dhabi: http://i49.tinypic.com/cnuhw.png
New York: http://i47.tinypic.com/20gz991.png

Does anybody have any insight to what may be causing this?

I would recommend you double-check that you're pulling the right columns from the EPW file. If you're following the documentation in "Weather Data Information" on
http://apps1.eere.energy.gov/buildings/energyplus/weatherdata_format_def.cfm
then the columns are counted 1,2,3,4,5,flags,6,7,... so that it easy to get confused. It's also likely that the script which you have written counts the fields starting with 0, not 1 like in the documentation.

Can you let us know which date your processing that produces the evening spike?

Thirdly, have you considered using gendaylit instead of gensky? gendaylit works really well with the Abu Dhabi data, and only produces one error in the entire year (not counting a dozen or so 'zenith warnings'). This probably means that the sky conditions in Abu Dhabi are rather Californian (or British :wink:

Axel

Dear David,

Did you maybe mix up direct normal and direct horizontal radiation data?
I have seen this type of graph in the past when Daysim users tried to
run an annual illuminance simulation using their own radiation data. You
could try to simply run an empty scene in Daysim loading in your epw
file.

Best,

Christoph

···

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Greg
Ward
Sent: Friday, February 26, 2010 7:17 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] Annual illuminance simulation anomaly

Hi David,

In the case of "cnuhw.png," it looks like you are specifying a
horizontal irradiance due to direct solar that is pretty high all the
way to sunset. Since the direct horizontal is proportional to the
sine of the solar altitude, and this goes to zero as the sun nears the
horizon, the corresponding radiance of the sun has to increase
dramatically to compensate.

A more realistic scenario would have the direct horizontal component
dropping to zero as the sun reaches the horizon. My guess is that
your weather files aren't calibrated properly to the hour, or their
direct measurements actually include a significant diffuse component.

Does anyone else have experience with this?

Cheers,
-Greg

From: David Smith <[email protected]>
Date: February 26, 2010 3:47:52 PM PST

Dear list,

I was beginning an attempt to look at annual illuminance using the
information in a weather file (Energy Plus). As an initial test, I
used gensky while providing explicitly the direct normal radiation and
diffuse horizontal radiation from the weather file.
There was no actual geometry in the scene, just the sun, sky, skyglow,
etc. I then tested the illuminance with rtrace -I for a sensor
directed in the +Z direction as well as looking directly at the sun
where ever it was at that time.

What I found was that at the end of the day, the sensor point directly
facing the sun spikes dramatically. I've tried it with two different
weather files with similar results. Also, other sensor points pointed
in the general direction of the sunset spike correspondingly.

Here are links to two images, each showing the hourly averages for the
month of June:

Abu Dhabi: http://i49.tinypic.com/cnuhw.png
New York: http://i47.tinypic.com/20gz991.png

Does anybody have any insight to what may be causing this?

Cheers,

--Dave

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

David,

As it happens, I use the EPW Abu Dhabi weather data to illustrate a point re: the Pearls Design System (sort of LEED specifically for Abu Dhabi). A visualisation of direct normal and diffuse horizontal illuminances doesn't show the effect you refer to -- scroll down to section 'Abu Dhabi climate':

http://www.iesd.dmu.ac.uk/~jm/doku.php?id=academic:daylight-compliance

[See page 'Daylight and Compliance' if the link gets mangled by your mailer.]

I had a closer look at the weather file data and it seems OK.

I have noticed an effect when processing weather files that can result in direct normal illuminances steadily (and unrealistically) increasing throughout the day. However, that happens when direct normal has to be calculated from global horizontal and diffuse horizontal. An offset in the time calibration of just half an hour can result in massive sunset values for direct normal. Also, I have come across EPW files where the the direct normal in particular can be dodgy -- perhaps because it was derived from other quantities with flakey time calibration.

None of this however helps to explain what you noticed. Also, I would have thought that your method would have resulted in a more-or-less exact match between weather file direct normal and predicted direct normal (ab=0). I'm guessing you are aiming your sensor towards the sun using the direction vectors you get from gensky, yes?

I'm puzzled too.

-John

···

-----------------------------------------------
Dr. John Mardaljevic
Reader in Daylight Modelling
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
http://www.iesd.dmu.ac.uk/~jm

Dear Radiance gurus,

First, thank you all very much for your help and suggestions. I also
should have mentioned that I initially turned to Daysim, but it was
having trouble with the geometry, and the only way to get the geometry
to compile was to use meshes.

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?
B. Is gendaylit a prudent way forward instead of gensky CIE skies for
this climate? What about other climates?

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).
2. As far as Greg's thought about basically having a large intensity
to generate high enough horizontal illuminance values, shouldn't that
be the case in the morning as well?
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).
4. I also ran an empty Daysim scene using the same weather file (60
minute step) with a sensor point at 0 0 0 in direction 0 0 1. I pulled
in the .ill file to the mix to compare it to the rest as well.
5. The vector to the sun is parsed out of gensky output, I assume that
it is very similar to the gendaylit vector, but I didn't check.

I ended up running the test loop over again with these additional bits
of information as well as plotting the actual information within the
weather file.

I've posted a chart of the June hourly averages for Abu Dhabi here:

Some thoughts:
+ I have a lot of confidence in the Daysim and gendaylit outputs that
seem to follow each other and other lines' trends.
+ I haven't looked at the Radmap code to see how it handles the
information, and I'm only part way through wrapping my head around
some of the annual simulation readings that were recently introduced
to the list.
+ I've read the ASHRAE papers on how the weather files were made. It's
like making laws or sausages - best not to look behind the scenes if
you want to appreciate them.

Any further insight is appreciated. Again, thank you.

Cheers,

--Dave

============ Python code snippet =============

# Important: Python is white-space sensitive, your (or my) mail
program may have fiddled with line breaks and the white-space

# Super simple unzipping of an epw file (comma separated values) into
an indexed dictionary
# Posted to Radiance general mailing list 20100302

import os

# define the files
path = "/home/dave/rad/test_annual"
epwfile = "abu.epw"

# define all the fields
data_types = "year,month,day,hour,minute,uncertainty,dry_bulb,dew_point,relative_humidity,pressure,extraterrestrial_horizontal_radiation,extraterrestrial_direct_normal_radiation,horizontal_ir_radiation,global_horizontal_radiation,direct_normal_radiation,diffuse_horizontal_radiation,global_horizontal_illuminance,direct_normal_illuminance,diffuse_horizontal_illuminance,zenith_luminance,wind_direction,wind_speed,total_sky_cover,opaque_sky_cover,visibility,ceiling,weather_observation,weather_codes,precipitation,aerosol_optical_depth,snow_depth,days_since_last_snowfall"

# get data from the weather file
os.chdir(path)
handle = open(path+os.sep+epwfile,"r")
raw = handle.read()
handle.close()
lines = raw.splitlines()

# figure out the average number of columns in each line, it's going to
be really close to the lengths of the data lines
counter = 0
tally = 0
for line in lines:
    counter+=1
    wxarray = line.split(',')
    tally+=len(wxarray)
linelength = int(round(1.0*tally/counter))

# try getting data out
for line in lines:
    if len(line.split(','))==linelength:
        wxarray = dict(map(None,data_types.split(','),line.split(',')))
        m = str(int(wxarray["month"]))
        d = str(int(wxarray["day"]))
        h = str(int(wxarray["hour"]))
        direct = str(int(wxarray["direct_normal_radiation"]))
        diffuse = str(int(wxarray["diffuse_horizontal_radiation"]))

        print m,d,h,direct,diffuse

Hi David,

John mentioned that a half hour variance can create massive spikes in direct normal irradiance at sunset when calculated from horizontal irradiance data. I think you have such a discrepancy at the root of your problem.

Irradiance data in weather files is typically the average over the previous hour. So the irradiance for 10:00 is actually the average irradiance from 9:00 to 10:00. If this is true of your weather data, then you should subtract a half hour from the time in the weather data for your gensky command. That way you are using the average sun position over the hour rather than the ending sun position.

Best,
Andy

···

On Mar 2, 2010, at 4:05 PM, David Smith wrote:

Dear Radiance gurus,

First, thank you all very much for your help and suggestions. I also
should have mentioned that I initially turned to Daysim, but it was
having trouble with the geometry, and the only way to get the geometry
to compile was to use meshes.

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?
B. Is gendaylit a prudent way forward instead of gensky CIE skies for
this climate? What about other climates?

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).
2. As far as Greg's thought about basically having a large intensity
to generate high enough horizontal illuminance values, shouldn't that
be the case in the morning as well?
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).
4. I also ran an empty Daysim scene using the same weather file (60
minute step) with a sensor point at 0 0 0 in direction 0 0 1. I pulled
in the .ill file to the mix to compare it to the rest as well.
5. The vector to the sun is parsed out of gensky output, I assume that
it is very similar to the gendaylit vector, but I didn't check.

I ended up running the test loop over again with these additional bits
of information as well as plotting the actual information within the
weather file.

I've posted a chart of the June hourly averages for Abu Dhabi here:
http://i47.tinypic.com/2r7a98m.png

Some thoughts:
+ I have a lot of confidence in the Daysim and gendaylit outputs that
seem to follow each other and other lines' trends.
+ I haven't looked at the Radmap code to see how it handles the
information, and I'm only part way through wrapping my head around
some of the annual simulation readings that were recently introduced
to the list.
+ I've read the ASHRAE papers on how the weather files were made. It's
like making laws or sausages - best not to look behind the scenes if
you want to appreciate them.

Any further insight is appreciated. Again, thank you.

Cheers,

--Dave

============ Python code snippet =============

# Important: Python is white-space sensitive, your (or my) mail
program may have fiddled with line breaks and the white-space

# Super simple unzipping of an epw file (comma separated values) into
an indexed dictionary
# Posted to Radiance general mailing list 20100302

import os

# define the files
path = "/home/dave/rad/test_annual"
epwfile = "abu.epw"

# define all the fields
data_types = "year,month,day,hour,minute,uncertainty,dry_bulb,dew_point,relative_humidity,pressure,extraterrestrial_horizontal_radiation,extraterrestrial_direct_normal_radiation,horizontal_ir_radiation,global_horizontal_radiation,direct_normal_radiation,diffuse_horizontal_radiation,global_horizontal_illuminance,direct_normal_illuminance,diffuse_horizontal_illuminance,zenith_luminance,wind_direction,wind_speed,total_sky_cover,opaque_sky_cover,visibility,ceiling,weather_observation,weather_codes,precipitation,aerosol_optical_depth,snow_depth,days_since_last_snowfall"

# get data from the weather file
os.chdir(path)
handle = open(path+os.sep+epwfile,"r")
raw = handle.read()
handle.close()
lines = raw.splitlines()

# figure out the average number of columns in each line, it's going to
be really close to the lengths of the data lines
counter = 0
tally = 0
for line in lines:
   counter+=1
   wxarray = line.split(',')
   tally+=len(wxarray)
linelength = int(round(1.0*tally/counter))

# try getting data out
for line in lines:
   if len(line.split(','))==linelength:
       wxarray = dict(map(None,data_types.split(','),line.split(',')))
       m = str(int(wxarray["month"]))
       d = str(int(wxarray["day"]))
       h = str(int(wxarray["hour"]))
       direct = str(int(wxarray["direct_normal_radiation"]))
       diffuse = str(int(wxarray["diffuse_horizontal_radiation"]))

       print m,d,h,direct,diffuse

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi David.

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

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

···

On Wed, Mar 3, 2010 at 12:05 AM, David Smith <[email protected]> wrote:

See Chapter 5 here for a comparison of sky models including Perez.

http://www.iesd.dmu.ac.uk/~jm/doku.php?id=resources:thesis

Skip to page 41 in the PDF (numbered 203) to see how Perez compares to a simple clear-overcast blend for predictions of *internal* illuminance against measured values in a full-size office space.

-John

···

-----------------------------------------------
Dr. John Mardaljevic
Reader in Daylight Modelling
Institute of Energy and Sustainable Development
De Montfort University
The Gateway
Leicester
LE1 9BH, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

[email protected]
http://www.iesd.dmu.ac.uk/~jm