Randance and different sky descriptions

Hello.

I have been evaluating a couple of different software programs that interface with Radiance. Unfortunately, my "standard" test models aren't producing the same results in each software; the results are different by at least a factor of 2. I'm trying to understand how each software is separately using Radiance to come up with daylight results. I believe this requires an understanding of how the sky files are generated. I spent some time today poking around the Radiance-online mailing lists, looking for sky file content clues, but I suspect that some of these concepts are above me. I did review the gensky document dated 4/24/98 and I found it informative. I'm hoping that the community might provide some insight on the content of two "comparable" sky files; please see below:

Software 1:

!gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00

skyfunc glow skyglow
0
0
4 0.7 0.8 1.0 0

skyglow source sky
0
0
4 0 0 1 180

skyfunc glow grndglow
0
0
4 0.05 0.1 0.07 0

grndglow source ground
0
0
4 0 0 -1 180

Software 2:

void light solar
0
0
3 11009526.873677 11009526.873677 11009526.873677

solar source sun
0
0
4 0.039983 -0.647611 0.760921 0.5

void brightfunc skyfunc
2 skybr IES_skybright.cal
0
7 1 15.092265 18.041592 0.649859 0.039983 -0.647611 0.760921

skyfunc glow skyglow
0
0
4 0.989 0.989 1.159 0

skyglow source sky
0
0
4 0.0 0.0 1.0 180

skyfunc glow groundglow
0
0
4 1.0 1.0 1.0 0

groundglow source ground
0
0
4 0.0 0.0 -1.0 180

Thank you. I appreciate any thoughts on the matter.

[Element Logo 4-27-12.png]<http://www.megroup.com/>

ALLISON BYGOTT, PE, LC, LEED-AP

ENGINEER

t: 303.382.1920 x4132

www.megroup.com<http://www.megroup.com>

[Signature Twitter]<https://twitter.com/#!/megroup> [Signature LinkedIn Logo] <http://www.linkedin.com/company/m-e-group>

···

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any attached file(s) are intended only for the use of the individual or entity to whom or to which it is addressed and may contain information that is privileged, confidential, proprietary, and trade secret. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or reproduction of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately and discard the original message and any attachment(s).

Hi Allison,

Nice to see you on the list! So what you have here is two different ways of specifying the sky. The first form ("Software 1"), the gensky command is given inline (hence the '!' that precedes the gensky command), and the STDOUT (which contains the skyfunc and the sun source description) are then passed on to the celestial hemisphere sky and ground primitives. In the second form, that STDOUT is explicitly listed in the sky description. If you simply try the "Software 1" sky description's gensky command at the command line, you get:

command:
gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00

output (STDOUT):
# gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00
# Local solar time: 11.87
# Solar altitude and azimuth: 49.5 -3.1
# Ground ambient level: 15.0

void light solar
0
0
3 6.88e+06 6.88e+06 6.88e+06

solar source sun
0
0
4 0.034560 -0.648139 0.760737 0.5

void brightfunc skyfunc
2 skybr skybright.cal
0
7 1 1.09e+01 2.30e+01 6.50e-01 0.034560 -0.648139 0.760737

You can see that these sections bear a resemblance to the first sections in your "Software 2" sky description in format, but not in value(s). Again, these are the bits that define the luminous sky and ground hemispheres, as well as the position and intensity of the sun. So clearly the Software 2 gensky input is different from the Software 1 gensky input. I can't back out what Software 2's gensky input must have looked like, although I'm sure a few people on this list may be able to. THe bigger issue is we need to know some more details about your test case, and the relative differences in the reported values from one software tool to the next. It would also be helpful to know what tools you are using, and how you are using them, rather than just trying to reverse engineer the inputs.

- Rob

···

On Feb 26, 2013, at 5:31 PM, Allison Bygott <[email protected]> wrote:

Hello.

I have been evaluating a couple of different software programs that interface with Radiance. Unfortunately, my "standard" test models aren't producing the same results in each software; the results are different by at least a factor of 2. I'm trying to understand how each software is separately using Radiance to come up with daylight results. I believe this requires an understanding of how the sky files are generated. I spent some time today poking around the Radiance-online mailing lists, looking for sky file content clues, but I suspect that some of these concepts are above me. I did review the gensky document dated 4/24/98 and I found it informative. I'm hoping that the community might provide some insight on the content of two "comparable" sky files; please see below:

Software 1:

!gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00

skyfunc glow skyglow
0
0
4 0.7 0.8 1.0 0

skyglow source sky
0
0
4 0 0 1 180

skyfunc glow grndglow
0
0
4 0.05 0.1 0.07 0

grndglow source ground
0
0
4 0 0 -1 180

Software 2:

void light solar
0
0
3 11009526.873677 11009526.873677 11009526.873677

solar source sun
0
0
4 0.039983 -0.647611 0.760921 0.5

void brightfunc skyfunc
2 skybr IES_skybright.cal
0
7 1 15.092265 18.041592 0.649859 0.039983 -0.647611 0.760921

skyfunc glow skyglow
0
0
4 0.989 0.989 1.159 0

skyglow source sky
0
0
4 0.0 0.0 1.0 180

skyfunc glow groundglow
0
0
4 1.0 1.0 1.0 0

groundglow source ground
0
0
4 0.0 0.0 -1.0 180

Thank you. I appreciate any thoughts on the matter.

<image002.png>

ALLISON BYGOTT, PE, LC, LEED-AP
ENGINEER
t: 303.382.1920 x4132
www.megroup.com
<image004.jpg><image006.jpg>

CONFIDENTIALITY NOTICE: This e-mail and any attached file(s) are intended only for the use of the individual or entity to whom or to which it is addressed and may contain information that is privileged, confidential, proprietary, and trade secret. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or reproduction of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately and discard the original message and any attachment(s).
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Does "Software 2" still have the "# gensky ..." line in it? That would tell you what parameters generated the output.

-Greg

···

From: Rob Guglielmetti <[email protected]>
Date: February 26, 2013 5:56:59 PM PST

Hi Allison,

Nice to see you on the list! So what you have here is two different ways of specifying the sky. The first form ("Software 1"), the gensky command is given inline (hence the '!' that precedes the gensky command), and the STDOUT (which contains the skyfunc and the sun source description) are then passed on to the celestial hemisphere sky and ground primitives. In the second form, that STDOUT is explicitly listed in the sky description. If you simply try the "Software 1" sky description's gensky command at the command line, you get:

command:
gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00

output (STDOUT):
# gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00
# Local solar time: 11.87
# Solar altitude and azimuth: 49.5 -3.1
# Ground ambient level: 15.0

void light solar
0
0
3 6.88e+06 6.88e+06 6.88e+06

solar source sun
0
0
4 0.034560 -0.648139 0.760737 0.5

void brightfunc skyfunc
2 skybr skybright.cal
0
7 1 1.09e+01 2.30e+01 6.50e-01 0.034560 -0.648139 0.760737

You can see that these sections bear a resemblance to the first sections in your "Software 2" sky description in format, but not in value(s). Again, these are the bits that define the luminous sky and ground hemispheres, as well as the position and intensity of the sun. So clearly the Software 2 gensky input is different from the Software 1 gensky input. I can't back out what Software 2's gensky input must have looked like, although I'm sure a few people on this list may be able to. THe bigger issue is we need to know some more details about your test case, and the relative differences in the reported values from one software tool to the next. It would also be helpful to know what tools you are using, and how you are using them, rather than just trying to reverse engineer the inputs.

- Rob

On Feb 26, 2013, at 5:31 PM, Allison Bygott <[email protected]> wrote:

Hello.

I have been evaluating a couple of different software programs that interface with Radiance. Unfortunately, my "standard" test models aren't producing the same results in each software; the results are different by at least a factor of 2. I'm trying to understand how each software is separately using Radiance to come up with daylight results. I believe this requires an understanding of how the sky files are generated. I spent some time today poking around the Radiance-online mailing lists, looking for sky file content clues, but I suspect that some of these concepts are above me. I did review the gensky document dated 4/24/98 and I found it informative. I'm hoping that the community might provide some insight on the content of two "comparable" sky files; please see below:

Software 1:

!gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00

skyfunc glow skyglow
0
0
4 0.7 0.8 1.0 0

skyglow source sky
0
0
4 0 0 1 180

skyfunc glow grndglow
0
0
4 0.05 0.1 0.07 0

grndglow source ground
0
0
4 0 0 -1 180

Software 2:

void light solar
0
0
3 11009526.873677 11009526.873677 11009526.873677

solar source sun
0
0
4 0.039983 -0.647611 0.760921 0.5

void brightfunc skyfunc
2 skybr IES_skybright.cal
0
7 1 15.092265 18.041592 0.649859 0.039983 -0.647611 0.760921

skyfunc glow skyglow
0
0
4 0.989 0.989 1.159 0

skyglow source sky
0
0
4 0.0 0.0 1.0 180

skyfunc glow groundglow
0
0
4 1.0 1.0 1.0 0

groundglow source ground
0
0
4 0.0 0.0 -1.0 180

Thank you. I appreciate any thoughts on the matter.

<image002.png>

ALLISON BYGOTT, PE, LC, LEED-AP
ENGINEER
t: 303.382.1920 x4132
www.megroup.com
<image004.jpg><image006.jpg>

Hi Allison,

Are these tests related to using lighting simulation for compliance purposes, e.g. LEED 'clear sky', ASHRAE? If so, caution is advised -- see sections on LEED & ASHRAE here:

http://climate-based-daylighting.com/doku.php?id=academic:daylight-compliance

Best
John

John Mardaljevic PhD FSLL
Professor of Building Daylight Modelling
School of Civil & Building Engineering
Loughborough University
Loughborough
Leicestershire
LE11 3TU, UK

Tel: +44 1509 222630 (Direct)
Tel: +44 1509 228529 (Pam Allen, secretary)

[email protected]
http://www.lboro.ac.uk/departments/cv/staff/profile/367.html

Personal daylighting website:
http://climate-based-daylighting.com

Hi Allison,

I have been doing some comparisons of some of these new daylight simulation
approaches recently as well. What we are seeing here is really why I
created an IES_gensky.py module that comes with SPOT and creates a clear,
pt cldy, and cldy skies according to IESNA recommendations (pre handbook
10, not sure if there were any changes). Software 2 (SPOT) uses
IES_gensky.py (and IES_skybright.cal) for it's "design day" calculations
and we are seeing the output from that. It then uses weather data to
adjust for its annual or specific day calculations. In creating SPOT we
felt these "design day" skies were still good to review as it can give a
better idea of the extremes a space might see. Relying solely on Perez
skies and weather data skies might not yield a perfectly sunny winter
solstice and while this may certainly be representative of a given climate
(Seattle :wink: one cannot claim a sunny winter equinox will never exist. Now
the town might be outside celebrating if this ever happens, making it all a
moot point, but I digress...

Here are the numbers I get for a Boulder, CO equinox clear and sunny sky at
noon from TMY2 weather data, IES_gensky, and gensky
Weather data = 7,893fc
IES_gensky (5,000elev) = 9,416fc
IES_gensky (0) = 8212fc
gensky = 5823fc

Your current SPOT sky is almost 2x that of gensky which should explain much
of your interior discrepancies. This sky did have an elevation adjustment
for 5,000ft. I would recommend taking that out and just using 0 elevation
which results in exact IES recommendations. The elevation factor was
derived from a weather study for higher elevation locations, and while I
think it works ok for really high elevations and high sun angles (it
matches our high mountain Colorado skies fairly well during the summer
months) it does not seem to help the Boulder sky. I guess there is too
much smoke in the air :wink:

I also looked at the difference in distribution and found none - which is
good as they both should be using the CIE recommended clear sky
distributions, just not the same magnitude. I put the sky definitions into
files and ran:
oconv 3_21_12.01_1.sky > SPOTsky.oct
rpict @calc.opt -vta -vp 0 0 0 -vd 0 0 1 -vu 0 1 0 -vv 180 -vh 180 -x 1250
-y 1250 SPOTsky.oct > SPOTsky.hdr
oconv e12pm_gensky.sky > Gensky.oct
rpict @calc.opt -vta -vp 0 0 0 -vd 0 0 1 -vu 0 1 0 -vv 180 -vh 180 -x 1250
-y 1250 Gensky.oct > Gensky.hdr
pcomb -e "ro=ri(1)/ri(2);go=gi(1)/gi(2);bo=bi(1)/bi(2)" SPOTsky.hdr
Gensky.hdr > SPOTgen_ratio.hdr (single back quotes on linux)

you can compare resulting illuminance (in fc) from these skies for global
and all orientations like so:
echo 0 0 0 0 0 1 | rtrace @calc.opt -h -I -faa -ov SPOTsky.oct | rcalc -e
"$1=$1*4.40805+$2*11.1436+$3*1.07777" > SPOTsky.dat
echo 0 0 0 1 0 0 | rtrace @calc.opt -h -I -faa -ov SPOTsky.oct | rcalc -e
"$1=$1*4.40805+$2*11.1436+$3*1.07777" > SPOTskyE.dat
echo 0 0 0 0 -1 0 | rtrace @calc.opt -h -I -faa -ov SPOTsky.oct | rcalc -e
"$1=$1*4.40805+$2*11.1436+$3*1.07777" > SPOTskyS.dat
echo 0 0 0 -1 0 0 | rtrace @calc.opt -h -I -faa -ov SPOTsky.oct | rcalc -e
"$1=$1*4.40805+$2*11.1436+$3*1.07777" > SPOTskyW.dat
echo 0 0 0 0 1 0 | rtrace @calc.opt -h -I -faa -ov SPOTsky.oct | rcalc -e
"$1=$1*4.40805+$2*11.1436+$3*1.07777" > SPOTskyN.dat

I hope this helps.

Regards,
Zack

···

On Tue, Feb 26, 2013 at 5:31 PM, Allison Bygott <[email protected]>wrote:

Hello.

I have been evaluating a couple of different software programs that
interface with Radiance. Unfortunately, my "standard" test models aren't
producing the same results in each software; the results are different by
at least a factor of 2. I'm trying to understand how each software is
separately using Radiance to come up with daylight results. I believe this
requires an understanding of how the sky files are generated. I spent some
time today poking around the Radiance-online mailing lists, looking for sky
file content clues, but I suspect that some of these concepts are above me.
I did review the gensky document dated 4/24/98 and I found it informative.
I'm hoping that the community might provide some insight on the content of
two "comparable" sky files; please see below:

Software 1:

!gensky 3 21 12.01 +s -a 40.03 -o 105.28 -m 105.00

skyfunc glow skyglow

0

0

4 0.7 0.8 1.0 0

skyglow source sky

0

0

4 0 0 1 180

skyfunc glow grndglow

0

0

4 0.05 0.1 0.07 0

grndglow source ground

0

0

4 0 0 -1 180

Software 2:

void light solar

0

0

3 11009526.873677 11009526.873677 11009526.873677

solar source sun

0

0

4 0.039983 -0.647611 0.760921 0.5

void brightfunc skyfunc

2 skybr IES_skybright.cal

0

7 1 15.092265 18.041592 0.649859 0.039983 -0.647611 0.760921

skyfunc glow skyglow

0

0

4 0.989 0.989 1.159 0

skyglow source sky

0

0

4 0.0 0.0 1.0 180

skyfunc glow groundglow

0

0

4 1.0 1.0 1.0 0

groundglow source ground

0

0

4 0.0 0.0 -1.0 180

Thank you. I appreciate any thoughts on the matter.

[image: Element Logo 4-27-12.png] <http://www.megroup.com/>

ALLISON BYGOTT, PE, LC, LEED-AP

ENGINEER

t: 303.382.1920 x4132

www.megroup.com

[image: Signature Twitter] <https://twitter.com/#!/megroup> [image:
Signature LinkedIn Logo] <http://www.linkedin.com/company/m-e-group>

------------------------------

CONFIDENTIALITY NOTICE: This e-mail and any attached file(s) are intended
only for the use of the individual or entity to whom or to which it is
addressed and may contain information that is privileged, confidential,
proprietary, and trade secret. If the reader of this message is not the
intended recipient or an employee or agent responsible for delivering the
message to the intended recipient, you are hereby notified that any
dissemination, distribution, or reproduction of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately and discard the original message and any
attachment(s).

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

--
Zack Rogers, P.E., LEED AP BD+C
Daylighting Innovations, LLC
211 North Public Road, Suite 220
Lafayette, CO 80026
(303)946-2310

Hi John, a quick comment on this study. While I agree it is not written up
very clearly, I do believe LEED intended a "clear sky" to be an IESNA
defined clear sky that would have a solar disc included and would use the
IES standardized formulas for deriving the diffuse (via a zenith luminance)
and direct illuminances. LEED v4.0 (yet to be released) has this new
sDA/ASE thing, have you had a chance to give that a spin? The challenge
seems to be in simulating blind control.

Cheers,
Zack

···

On Wed, Feb 27, 2013 at 2:18 AM, John Mardaljevic <[email protected] > wrote:

Hi Allison,

Are these tests related to using lighting simulation for compliance
purposes, e.g. LEED 'clear sky', ASHRAE? If so, caution is advised -- see
sections on LEED & ASHRAE here:

http://climate-based-daylighting.com/doku.php?id=academic:daylight-compliance

Best
John

John Mardaljevic PhD FSLL
Professor of Building Daylight Modelling
School of Civil & Building Engineering
Loughborough University
Loughborough
Leicestershire
LE11 3TU, UK

Tel: +44 1509 222630 (Direct)
Tel: +44 1509 228529 (Pam Allen, secretary)

[email protected]
http://www.lboro.ac.uk/departments/cv/staff/profile/367.html

Personal daylighting website:
http://climate-based-daylighting.com

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

--
Zack Rogers, P.E., LEED AP BD+C
Daylighting Innovations, LLC
211 North Public Road, Suite 220
Lafayette, CO 80026
(303)946-2310

Wow, thanks for this investigation, Zack! Replies below.

···

On 2/28/13 1:58 PM, "Zack Rogers" <[email protected]<mailto:[email protected]>> wrote:

Here are the numbers I get for a Boulder, CO equinox clear and sunny sky at noon from TMY2 weather data, IES_gensky, and gensky
Weather data = 7,893fc
IES_gensky (5,000elev) = 9,416fc
IES_gensky (0) = 8212fc
gensky = 5823fc

Wow, that's quite a spread. Might be interesting to throw in an "ideally clear" day using the Perez model and see where that ends up on this continuum -- and then go from there, because clearly this should be discussed further.

You should be able to find an ideally clear direct normal/diffuse horizontal pair of values hovering around the Equinox for Boulder in the TMY/EPW set. When you see something like a 10:1 ratio between the direct normal and the diffuse horizontal irradiance, you can bet you're looking at a cloudless sky — certainly an unobscured sun, and vice-versa for a Portland/Seattle (er, overcast) sky. See this link for example:

This is for Summer Solstice, but you get the idea. Somewhere near the Equinox there should be a day where this 10:1 ratio is evident, and you could use that day and value pair with gensky, IES_gensky, and gendaylit and see what you get. Since gensky can also take these values as input (and presumably so can IES_gensky but I'm not certain), this might give us more of an "apples to apples" comparison. Also when using direct input of irradiance, you obviously don't want to use the cool elevation correction in IES_gensky, since the actual elevation of the instrumentation handles this for you. =)

- Rob

Hi Zack,

I was completely bemused by the original LEED 2.2 'clear sky' option when I first read it. Whatever may have been intended, since no supplementary data were given, prospective users have had to guess what the formulators of the option had in mind. I believe that one or more commercial software packages do indeed predict for a clear sky without sun when the 'clear sky' option is selected. To my mind, the ASHRAE option, which allows the user to select either clear or overcast skies, makes matters worse rather than better. The draft LEED v4.0 is definitely a step in the right direction -- or, at least, the part where the evaluation is founded on a full year. However, you are right to flag that simulating blind control is a big (think: really HUGE) issue since so much of the outcome depends on the initial assumptions. The accurate evaluation of blinds is doubly confounded: once by the uncertainty regarding when users lower blinds and by how much; and, secondly by the huge sensitivity of blind photometric properties (BSDF) to relatively subtle (and largely unpredictable) users tweaks of, say, the slat-tilt.

I believe we also share the concern that the draft formulation might do little, if anything, to encourage the selection of an effective static shading design over a floor-to-ceiling glass box with blinds.

Radiance-general might no be the most appropriate place to have these issues aired/debated, but I'm not aware that it's happening anywhere else. Also, Radiance, or rather gensky, seems to be being replied upon to perform a task for which it was never designed, i.e. generating 'snap-shot' sky conditions for compliance purposes.

Cheerio
John

John Mardaljevic PhD FSLL
Professor of Building Daylight Modelling
School of Civil & Building Engineering
Loughborough University
Loughborough
Leicestershire
LE11 3TU, UK

Tel: +44 1509 222630 (Direct)
Tel: +44 1509 228529 (Pam Allen, secretary)

[email protected]<mailto:[email protected]>
http://www.lboro.ac.uk/departments/cv/staff/profile/367.html<http://www.lboro.ac.uk/departments/cv/>

Personal daylighting website:
http://climate-based-daylighting.com<http://climate-based-daylighting.com/>

Hey Rob,

So, as expected, Perez returns roughly the same illuminance fed to it. I
used the clearest noon I could find around equinox, with a 9.76:1 (dir
nor/diff) ratio (3-19 at 12pm in the Boulder TMY2 file). I get 8360fc
where the global illum is listed as 8259fc, which I'd say is equivalent.
Looking at the percent difference between the resulting Perez sky and
IESNA recommendation is interesting. The perez sky has the north horizon
roughly 1.2x brighter, the south horizon about .9X as bright, and the
circumsolar reqion about ~1.3x brighter. The ratio image is here:
https://dl.dropbox.com/u/14937994/perezdivSPOT_fls.png (this is the perez
sky divided by the IESNA sky for a sunny equinox at noon in Boulder, CO)

Cheers,
Zack

···

On Thu, Feb 28, 2013 at 3:13 PM, Guglielmetti, Robert < [email protected]> wrote:

Wow, thanks for this investigation, Zack! Replies below.

On 2/28/13 1:58 PM, "Zack Rogers" <[email protected] > <mailto:[email protected]>> wrote:

Here are the numbers I get for a Boulder, CO equinox clear and sunny sky
at noon from TMY2 weather data, IES_gensky, and gensky
Weather data = 7,893fc
IES_gensky (5,000elev) = 9,416fc
IES_gensky (0) = 8212fc
gensky = 5823fc

Wow, that's quite a spread. Might be interesting to throw in an "ideally
clear" day using the Perez model and see where that ends up on this
continuum -- and then go from there, because clearly this should be
discussed further.

You should be able to find an ideally clear direct normal/diffuse
horizontal pair of values hovering around the Equinox for Boulder in the
TMY/EPW set. When you see something like a 10:1 ratio between the direct
normal and the diffuse horizontal irradiance, you can bet you're looking at
a cloudless sky — certainly an unobscured sun, and vice-versa for a
Portland/Seattle (er, overcast) sky. See this link for example:

https://www.dropbox.com/s/ri505ka29rr6knq/perez_skies.pdf

This is for Summer Solstice, but you get the idea. Somewhere near the
Equinox there should be a day where this 10:1 ratio is evident, and you
could use that day and value pair with gensky, IES_gensky, and gendaylit
and see what you get. Since gensky can also take these values as input (and
presumably so can IES_gensky but I'm not certain), this might give us more
of an "apples to apples" comparison. Also when using direct input of
irradiance, you obviously don't want to use the cool elevation correction
in IES_gensky, since the actual elevation of the instrumentation handles
this for you. =)

- Rob

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

--
Zack Rogers, P.E., LEED AP BD+C
Daylighting Innovations, LLC
211 North Public Road, Suite 220
Lafayette, CO 80026
(303)946-2310