gendaylit

Dear Radiance experts:

try this with gendaylit:

gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 20.5 200.5

This is for Pittsburgh. The weather station data are 20.5 W/m^2 diffuse horizontal and 200.5 W/m^2 for the "beam" component (towards the sun). Both irradiance data are in the visible range only.

I expect 46.8 W/m^2 from the sun, measured on the horizontal plane, since the sine of the sun altitude angle multiplied by 200.5 gives 46.8

What I get is 21 W/m^2. Does the gendaylit -W option require W/m^2 measured over the full spectrum? The gendaylit man page says it uses data based on the visible spectrum.

I asked someone who used gendaylit previously and this is what he wrote:

···

------------------------------------------------------------------------
"Martin,

try this with gendaylit:

gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 20.5 200.5

I did. Here's what I got -

gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 20.5 200.5
# gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 20.5 200.5
sky clearness or sky brightness out of range 1.029410 0.620136

Hmmm... It appears we are using different versions.
Are you using, as I am, UNIX or some PC version?

The header for my gendaylit.c is:

/* Copyright (c) 1994 *Fraunhofer Institut for Solar Energy Systems
* Oltmannstr 5, D-79100 Freiburg, Germany
* *Agence de l'Environnement et de la Maitrise de
l'Energie
* Centre de Valbonne, 500 route des Lucioles,
06565 Sophia Antipolis Cedex, France
* *BOUYGUES
* 1 Avenue Eugene Freyssinet,
Saint-Quentin-Yvelines, France
*/

And for the cal file:

{ SCCSid "@(#)perezlum.cal 2.5 15/02/94 ISE" }

I haven't used gendaylit for ages, I tend to stick with the sky
blends described in the thesis chapter. I'm still a little concerned
that Perez can give unexpected distortions.
"

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

This makes things even more confusing. Any suggestions? I am using Redhat 7.2.

Martin

Dr.-Ing Martin Moeck, Assistant Professor
Pennsylvania State University
Department of Architectural Engineering
USA - University Park, PA 16802
e-mail [email protected]
http://www.engr.psu.edu/ae

Martin,

It seems you have inverted the parameters providing direct beam irradiance
and diffuse global irradiance.
So instead of calling: gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 20.5 200.5
do this:

gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 200.5 20.5

My experience with gendaylit is that it is a rather reliable program. Its
validation is documented in gendaylit author's master thesis.

Rapha�l Compagnon

···

__________________________________________________________
Raphael Compagnon
HES-SO Ecole d'ingenieurs et d'architectes de Fribourg
Bd. de Perolles 80, 1705 Fribourg Switzerland
Tel: +41 26 429 6666 or +41 26 429 6611 (secretariat)
Fax: +41 26 429 6600
E-Mail: [email protected] WWW: http://www.eif.ch

Rapha�l wrote:

My experience with gendaylit is that it is a rather reliable
program. Its
validation is documented in gendaylit author's master thesis.

I can add to this that my former colleagues at the Fraunhofer ISE and I have
been using gendaylit extensively over the past years and all in all the
results seem to be very reliable under a wide range of sky conditions (just
around sunrise and sunset you can easily run into errors).

We kind of "validated" the gendaylit source code in a study in which be
measured and simulated indoor illuminances based on direct/diffuse
irradiances under over 10,000 sky conditions and the results were rather
encouraging.

C. F. Reinhart, 0. Walkenhorst, "Dynamic RADIANCE-based Daylight Simulations
for a full-scale Test Office with outer Venetian Blinds", Energy &
Buildings, Vol. 33 pp. 683-697, 2001

In case anybody wants the pdf-file, just drop me a line.

Christoph

Christoph Tito Reinhart, Dr. Ing., Dipl.-Phys., M.Sc. tel: (613) 993-9703
Research Officer
fax: (613) 954-3733
m 24 Institute for Research in Construction e-mail:
[email protected]
National Research Council Canada
http://www.nrc.ca/irc/ie/light/daysim.html
Montreal Road, Ottawa Ont K1A
0R6, Canada

In the Radiance validation I carried out using measured sky luminances, I
also tested a number of sky models including Perez (gendaylit).

Of the 754 skies, there were 41 for which the Perez model description could
either not be generated (outside parameter range - 27 skies) or which produced
negative vertical illuminances (14 skies). These were eliminated from the analysis
for this model leaving 713 skies. The negative vertical illuminances
resulted from distortions in the sky luminance distribution that can
occur unexpectedly for certain combinations of input parameters. These
parameter combinations were present in the data collected by the BRE
but they were not encountered in the Berkeley data that were used to
derive the model. This effect was noted by Littlefair and an
adjustment to the model to prevent this distortion was advised by
Perez. A routine examination of the gendaylit code showed this fix
to be present. So it would appear not to correct all occurrences.

The presence of a distortion was taken to be a negative value for any
of the predicted vertical illuminances. The actual luminance distribution
for the sky was not examined. So the possibility remains that some of
the other skies may yet have exhibited some distortion.

The distortion manifested itself, weirdly, as a region of -ve luminance
sky that could be seen in rview as a conspicuous strangely coloured patch.
Note, Radiance (v2.4) didn't complain that -ve luminances were encountered
when rays 'hit' the glow material. Which is fair enough, who'd expect -ve
luminances to be present? Also, -ve luminances notwithstanding, the diffuse
horizontal illuminance predicted using rtrace was *correct*. So, other
parts of the sky were no doubt high (+ve) luminance to compensate. As
noted above, a minimum test that distortions were not present would be
reasonable predictions for vertical illuminances from the Perez sky. To
be certain, you'd really have to test individual rays that sampled the
hemisphere.

The above is a report of what happened. I'm not suggesting that Perez/gendaylit
should not be used. In fact, as far as I recall, the parameters that led
to these distortions were also around sunrise/sunset with diffuse horizontal
illuminances of only a few klux - not a big deal for daylighting/energy calcs.
Rather, i'd caution that strange things can happen (or at least did) when gendaylit
is (was) routinely used to generate skies from measured data.

For desperate insomniacs, sky model tests (Chapter 5) and other stuff can
be downloaded from here:

http://www.iesd.dmu.ac.uk/~jm/zxcv-thesis/

Sleep well....

-John Mardaljevic

···

-----------------------------------------------
Dr. John Mardaljevic
Senior Research Fellow
Institute of Energy and Sustainable Development
De Montfort University
Scraptoft
Leicester LE7 9SU, UK
+44 (0) 116 257 7972
+44 (0) 116 257 7981 (fax)

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

Martin,

two errors in your gendaylit command line:
1. You mixed up direct and diffuse radiation
2. Gendaylit uses the full spectrum irradiation as input! It's the default output which is in the visible range. The Perez model (and gendaylit) calculates the luminous efficacy (W -> lm) according the actual sky state.
How can you measure irradiantion in the visible range only?

Concerning the reliability, I can underline the statement from Christoph. Besides these mentioned validations, we did additional validations (measurements of direct and diffuse irradiation and horizontal and 4 vertical illuminance) years ago with 10sec data for a dataset of one year and found a good match between measurements and the model.
Of course, for extrem low sun position, the model could have some problems - but also the correct measurements of these flat sun positions is often critical. And be careful if you have mean values and not actual values (e.g. 1 value for an interval of an hour or 15 min)! This can lead also to problems at sunset/sunrise!

Jan

···

-------------------------------------------------------------------
   o - > \ Jan Wienold
                 Fraunhofer Institute for Solar Energy Systems
                 SOLAR BUILDING DESIGN GROUP - DAYLIGHTING
                 Heidenhofstr. 2
                 79110 Freiburg
                 GERMANY
                                 Phone: ++49 - (0) 761 - 4588 -5- 133
                 Fax: ++49 - (0) 761 - 4588 -9- 133
                 Email: [email protected]
                                 Internet:
                 http://www.ise.fhg.de

I did what you suggested, Raphael.

Again, the weather station data for Pittsbugh tell me that the diffuse horizontal component is 41 W/m^2, and the "beam" component measured towards the sun is 401 W/m^2

I was shortcutting the luminous efficacy of these values by dividing both values by 2, assuming that approximately 50% are in the visible range. That was a mistake.

gendaylit's man page generates a CIE clear sky as follows:
gendaylit -ang 60 0 -W 840 135

These irradiance data are integrated over the full spectrum, not just the visible range. Therefore:
gendaylit 4 13 7 -a 40.3 -o 79.9 -m 75 -W 401 41
This gives me horizontal irradiance values of 41 for the sun and 38 for the sky, which is ok.

The important difference between gendaylit and gensky is the input of irradiance data. If those data given to gensky -B -R are integrated over the full spectrum, not just the visible range, interior daylight levels will double! Gensky wants W/m^2 in the visible range only, whereas gendaylit uses the actual irradiance data from weather stations, which are approx. twice as high.

Martin

···

-----Original Message-----
  From: Raphaël Compagnon [mailto:[email protected]]
  Sent: Thu 6/13/2002 7:37 AM
  To: [email protected]
  Cc: Martin Moeck
  Subject: Re: gendaylit
  
  Martin,
  
  It seems you have inverted the parameters providing direct beam irradiance
  and diffuse global irradiance.
  So instead of calling: gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 20.5 200.5
  do this:
  
  gendaylit 4 13 7 -a 40.3 -o 79.4 -m 75 -W 200.5 20.5
  
  My experience with gendaylit is that it is a rather reliable program. Its
  validation is documented in gendaylit author's master thesis.
  
  Raphaël Compagnon

Hi Martin,

You are right that the irradiance data fed to gensky should be treated
with caution. The reason for this, however, is Radiance’s use of a
constant luminous efficacy of 179 lm/W. If you want accurate
interior daylight levels using gensky, you should use illuminance data if
you have it, rather than irradiance data. simply take the
illuminance data and divide it by 179 lm/W to get ‘pseudo-irradiances’ to
feed to gensky. it is highly likely that this will not equal
measured irradiance data as realistic sky luminous efficacies are between
90 & 150 lm/W. if you have irradiance data only, that should be
first multiplied by a reasonable luminous efficacy (refer for example,
Lam, J.C. and Li, D.H.W. (1996), Luminous Efficacy of Daylight under
Different Sky Conditions,
Energy Conservation and Management*,*
37 (12), 1703-1711) to get illuminance data. then follow the same
process to get your ‘pseudo-irradiances’ for input to gensky.

Regards,

Phil Greenup.

···

The important difference between gendaylit and
gensky is the input of irradiance data. If those data given to gensky -B
-R are integrated over the full spectrum, not just the visible range,
interior daylight levels will double! Gensky wants W/m^2 in the visible
range only, whereas gendaylit uses the actual irradiance data from
weather stations, which are approx. twice as high.

Martin

I'm sure I had it working on Windows once but I now can't get it to pick
up the coeff_perez.dat file - it's in my radiance/lib folder, correctly
specified in my RADPATH variable. Should it be somewhere else?

Compiling on Ubuntu 7.10 seems to work, albeit with the following
warning:

gcc -c fropen.c
fropen.c: In function ‘fropen’:
fropen.c:45: warning: incompatible implicit declaration of built-in
function ‘strcpy’

Should I worry about this?

Finally, which output option should I use if I want similar output to
gensky, W/m2.sr (solar), W/m2.sr (visible), or lm/m2.sr. I'm guessing
the former?

Nick

Hi Nick,

Use default value - 0, since Radiance output is in radiance values for
visible part of light.

Note:
- if you are using irradiance values from EPW files use -W dir_norm
diff_horiz
- if you are using irradiance values from Stal-light files (for Europe) use
-G dir_horiz dif_horiz

Don't worry for fropen error on Ubuntu

Marija

···

2008/9/24 Nick Doylend <[email protected]>

I'm sure I had it working on Windows once but I now can't get it to pick
up the coeff_perez.dat file - it's in my radiance/lib folder, correctly
specified in my RADPATH variable. Should it be somewhere else?

Compiling on Ubuntu 7.10 seems to work, albeit with the following
warning:

gcc -c fropen.c
fropen.c: In function 'fropen':
fropen.c:45: warning: incompatible implicit declaration of built-in
function 'strcpy'

Should I worry about this?

Finally, which output option should I use if I want similar output to
gensky, W/m2.sr (solar), W/m2.sr (visible), or lm/m2.sr. I'm guessing
the former?

Nick

dear users
Can someone tell me the steps to install gendaylit?
Could I use it for DF (overcast sky), or I must to use gensky with -c
option? I ask you this because using gensky I get a very low DF value.
thanks in advance
Roberto

Passa a Tiscali Tutto Incluso Light: telefono + adsl 8 Mb senza limiti a soli 9,95 euro al mese fino al 01/04/2010. Gratis la Sim Tiscali Mobile con 25 euro di traffico.L’offerta è valida solo se attivi entro il 05/11/09 http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw

Roberto.

Gendaylit would not help you to improve your DF results. The overcast
sky created by gensky is the CIE standard overcast sky which is
used for DF/ADF calculations.

If you think your results are to low you should check your the conversion
from radiance values to DF. Are you using the right options for rtrace?
Is your reference value (unobstructed sky) correct?

Regards,
Thomas

···

On Thu, Nov 5, 2009 at 11:43 AM, [email protected] <[email protected]> wrote:

dear users
Can someone tell me the steps to install gendaylit?
Could I use it for DF (overcast sky), or I must to use gensky with -c
option? I ask you this because using gensky I get a very low DF value.
thanks in advance
Roberto

Passa a Tiscali Tutto Incluso Light: telefono + adsl 8 Mb senza limiti a soli 9,95 euro al mese fino al 01/04/2010. Gratis la Sim Tiscali Mobile con 25 euro di traffico.L’offerta è valida solo se attivi entro il 05/11/09 http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw

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

Roberto,

Use of gendaylit for overcast sky conditions would be wrong because the 'overcast' skies (note plural) produced by the Perez All-Weather model do not correspond to the strict CIE definition, i.e. L_alt = L_zenith(1 + 2sin(alt))/3.

Actually, gendaylit gives you a range of overcast types depending on the absolute diffuse horizontal illuminance. The ratio between zenith and horizon luminance seems to increase with higher values for horizontal illuminance. As several users have noted, gendaylit bombs out with a warning:

Warning : skyclearness or skybrightness out of range ;
  Check your input parameters

for certain input values. The minimum diffuse horizontal illuminance that works appears to be 8603 (lux). Try:

gendaylit 7 1 12 -L 0 8603

gendaylit 7 1 12 -L 0 8602

The diffuse horizontal illuminance upper limit for an 'overcast' sky (i.e. direct normal illuminance = 0) is somewhere 80kLux and 90kLux. Which is, of course, improbably high for any sort of overcast sky.

-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 All,

I am using Perez sky model (gendaylit) in Radiance. When I calculate the
horizontal irradiance and compare it with global irradiance sensor I get
systematic error (rtrace gives around 70% lower values). I checked
everything in between so far nothing was wrong in the code, Here is one
sample:

gendaylit -ang 22.11 -64.30 -W 370.67 108.20 > genday_03_22_07_20.rad

then I add the sky description in the rad file:

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

void glow groundglow
0
0
4 1 1 1 0
groundglow source ground
0
0
4 0 0 -1 180

then I create an octree file:

oconv genday_03_22_07_20.rad > genday_03_22_07_20.oct

after that using rtrace I calculated the horizontal irradiance which is:
150.718 w/m^2

echo '0 0 0 0 0 1' | rtrace -w -ab 7 -ad 4096 -ar 512 -aa 0.1 -as 64 -I -h
genday_03_22_07_20.oct | rcalc -e '$1=$1*0.265+$2*0.67+$3*0.065'

150.718

but the measured global horizontal irradiance
(Pyranometer)
is 252.2 w/m^
2

I calculated this output for the whole year but still the Perez is
significantly underestimating the horizontal irradiance. I should add that
I used gensky to generate the same output and results showed gensky
horizontal irradiance fit well with Pyranometer irradiance. Does anyone
have any idea what is wrong here?

Thank you all, Ehsan

Hi Ehsan,

Could this be the difference between irradiance measured over the entire spectrum (as measured by a pyranometer) and the visible-spectrum irradiance as reported by rtrace? I believe there is a conversion factor in gendaylit that converts one to the other, but Jan Wienold or Wendelin Sprenger would know better.

-Greg

···

From: "Ehsan M.Vazifeh" <[email protected]>
Subject: [Radiance-general] gendaylit
Date: July 30, 2014 9:36:03 AM PDT

Dear All,

I am using Perez sky model (gendaylit) in Radiance. When I calculate the horizontal irradiance and compare it with global irradiance sensor I get systematic error (rtrace gives around 70% lower values). I checked everything in between so far nothing was wrong in the code, Here is one sample:

gendaylit -ang 22.11 -64.30 -W 370.67 108.20 > genday_03_22_07_20.rad

then I add the sky description in the rad file:

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

void glow groundglow
0
0
4 1 1 1 0
groundglow source ground
0
0
4 0 0 -1 180

then I create an octree file:

oconv genday_03_22_07_20.rad > genday_03_22_07_20.oct

after that using rtrace I calculated the horizontal irradiance which is: 150.718 w/m^2

echo '0 0 0 0 0 1' | rtrace -w -ab 7 -ad 4096 -ar 512 -aa 0.1 -as 64 -I -h genday_03_22_07_20.oct | rcalc -e '$1=$1*0.265+$2*0.67+$3*0.065’

150.718

but the measured global horizontal irradiance (Pyranometer) is 252.2 w/m^2

I calculated this output for the whole year but still the Perez is significantly underestimating the horizontal irradiance. I should add that I used gensky to generate the same output and results showed gensky horizontal irradiance fit well with Pyranometer irradiance. Does anyone have any idea what is wrong here?

Thank you all, Ehsan

if you want to have solar raditaion output in W/m2, then you have to use the -O 1 option for gendaylit (see manpage).
in your case, you get then 246 W/m2 calculated...

cheers,
Jan

···

Am 7/30/14, 6:36 PM, schrieb Ehsan M.Vazifeh:

Dear All,

I am using Perez sky model (gendaylit) in Radiance. When I calculate the horizontal irradiance and compare it with global irradiance sensor I get systematic error (rtrace gives around 70% lower values). I checked everything in between so far nothing was wrong in the code, Here is one sample:

gendaylit -ang 22.11 -64.30 -W 370.67 108.20 > genday_03_22_07_20.rad

then I add the sky description in the rad file:

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

void glow groundglow
0
4 1 1 1 0
groundglow source ground
0
4 0 0 -1 180

then I create an octree file:

oconv genday_03_22_07_20.rad > genday_03_22_07_20.oct

after that using rtrace I calculated the horizontal irradiance which is: 150.718 w/m^2

echo '0 0 0 0 0 1' | rtrace -w -ab 7 -ad 4096 -ar 512 -aa 0.1 -as 64 -I -h genday_03_22_07_20.oct | rcalc -e '$1=$1*0.265+$2*0.67+$3*0.065'

150.718

but the measured global horizontal irradiance
(Pyranometer)
is 252.2 w/m^
2

I calculated this output for the whole year but still the Perez is significantly underestimating the horizontal irradiance. I should add that I used gensky to generate the same output and results showed gensky horizontal irradiance fit well with Pyranometer irradiance. Does anyone have any idea what is wrong here?

Thank you all, Ehsan

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

Dear Jan and Greg,

Thank you all. using -O option solved the problem. I didn’t think about the spectrum other than visible.

Cheers, Ehsan

···

On 30 Jul 2014, at 18:49, Jan Wienold <[email protected]> wrote:

if you want to have solar raditaion output in W/m2, then you have to use the -O 1 option for gendaylit (see manpage).
in your case, you get then 246 W/m2 calculated...

cheers,
Jan

Am 7/30/14, 6:36 PM, schrieb Ehsan M.Vazifeh:

Dear All,

I am using Perez sky model (gendaylit) in Radiance. When I calculate the horizontal irradiance and compare it with global irradiance sensor I get systematic error (rtrace gives around 70% lower values). I checked everything in between so far nothing was wrong in the code, Here is one sample:

gendaylit -ang 22.11 -64.30 -W 370.67 108.20 > genday_03_22_07_20.rad

then I add the sky description in the rad file:

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

void glow groundglow
0
0
4 1 1 1 0
groundglow source ground
0
0
4 0 0 -1 180

then I create an octree file:

oconv genday_03_22_07_20.rad > genday_03_22_07_20.oct

after that using rtrace I calculated the horizontal irradiance which is: 150.718 w/m^2

echo '0 0 0 0 0 1' | rtrace -w -ab 7 -ad 4096 -ar 512 -aa 0.1 -as 64 -I -h genday_03_22_07_20.oct | rcalc -e '$1=$1*0.265+$2*0.67+$3*0.065’

150.718

but the measured global horizontal irradiance
(Pyranometer)
is 252.2 w/m^
2

I calculated this output for the whole year but still the Perez is significantly underestimating the horizontal irradiance. I should add that I used gensky to generate the same output and results showed gensky horizontal irradiance fit well with Pyranometer irradiance. Does anyone have any idea what is wrong here?

Thank you all, Ehsan

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

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

Dear Ehsan,

just one more comment - if you use the -O 1 option, the simulation is performed in the solar spectrum, so you can't calculate the visible range with it (because you don't use the in-built luminance efficacy model). For solar spetrum calculations, you also need reflectance/transmission values for the solar range. For spectral sensitive materials/coatings, the difference can be huge. (e.g. for glazing).
So for daylight simulations, you should use the default option of gendaylit, then the luminance efficacy is calculated for the sky/sun condition according to the Perez efficacy model.

Cheers,

Jan

···

Am 7/31/14, 9:31 AM, schrieb Ehsan Vazifeh:

Dear Jan and Greg,

Thank you all. using -O option solved the problem. I didn't think about the spectrum other than visible.

Cheers, Ehsan

On 30 Jul 2014, at 18:49, Jan Wienold <[email protected] > <mailto:[email protected]>> wrote:

if you want to have solar raditaion output in W/m2, then you have to use the -O 1 option for gendaylit (see manpage).
in your case, you get then 246 W/m2 calculated...

cheers,
Jan

Am 7/30/14, 6:36 PM, schrieb Ehsan M.Vazifeh:

Dear All,

I am using Perez sky model (gendaylit) in Radiance. When I calculate the horizontal irradiance and compare it with global irradiance sensor I get systematic error (rtrace gives around 70% lower values). I checked everything in between so far nothing was wrong in the code, Here is one sample:

gendaylit -ang 22.11 -64.30 -W 370.67 108.20 > genday_03_22_07_20.rad

then I add the sky description in the rad file:

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

void glow groundglow
0
4 1 1 1 0
groundglow source ground
0
4 0 0 -1 180

then I create an octree file:

oconv genday_03_22_07_20.rad > genday_03_22_07_20.oct

after that using rtrace I calculated the horizontal irradiance which is: 150.718 w/m^2

echo '0 0 0 0 0 1' | rtrace -w -ab 7 -ad 4096 -ar 512 -aa 0.1 -as 64 -I -h genday_03_22_07_20.oct | rcalc -e '$1=$1*0.265+$2*0.67+$3*0.065'

150.718

but the measured global horizontal irradiance
(Pyranometer)
is 252.2 w/m^
2

I calculated this output for the whole year but still the Perez is significantly underestimating the horizontal irradiance. I should add that I used gensky to generate the same output and results showed gensky horizontal irradiance fit well with Pyranometer irradiance. Does anyone have any idea what is wrong here?

Thank you all, Ehsan

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

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

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

Dear Jan,

Thanks again for this useful information. Actually, at the moment, my work
is comparison of different sky models with measurements from sky scanner.
And as I am working with the radiance and irradiance values there should be
no problem with using -O 1 option.

Bests, Ehsan

···

On Thu, Jul 31, 2014 at 10:34 AM, Jan Wienold <[email protected]> wrote:

Dear Ehsan,

just one more comment - if you use the -O 1 option, the simulation is
performed in the solar spectrum, so you can't calculate the visible range
with it (because you don't use the in-built luminance efficacy model). For
solar spetrum calculations, you also need reflectance/transmission values
for the solar range. For spectral sensitive materials/coatings, the
difference can be huge. (e.g. for glazing).
So for daylight simulations, you should use the default option of
gendaylit, then the luminance efficacy is calculated for the sky/sun
condition according to the Perez efficacy model.

Cheers,

Jan

Am 7/31/14, 9:31 AM, schrieb Ehsan Vazifeh:

Dear Jan and Greg,

Thank you all. using -O option solved the problem. I didn't think about
the spectrum other than visible.

Cheers, Ehsan

On 30 Jul 2014, at 18:49, Jan Wienold <[email protected]> wrote:

if you want to have solar raditaion output in W/m2, then you have to use
the -O 1 option for gendaylit (see manpage).
in your case, you get then 246 W/m2 calculated...

cheers,
Jan

Am 7/30/14, 6:36 PM, schrieb Ehsan M.Vazifeh:

Dear All,

I am using Perez sky model (gendaylit) in Radiance. When I calculate the
horizontal irradiance and compare it with global irradiance sensor I get
systematic error (rtrace gives around 70% lower values). I checked
everything in between so far nothing was wrong in the code, Here is one
sample:

gendaylit -ang 22.11 -64.30 -W 370.67 108.20 > genday_03_22_07_20.rad

then I add the sky description in the rad file:

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

void glow groundglow
0
0
4 1 1 1 0
groundglow source ground
0
0
4 0 0 -1 180

then I create an octree file:

oconv genday_03_22_07_20.rad > genday_03_22_07_20.oct

after that using rtrace I calculated the horizontal irradiance which is:
150.718 w/m^2

echo '0 0 0 0 0 1' | rtrace -w -ab 7 -ad 4096 -ar 512 -aa 0.1 -as 64 -I -h
genday_03_22_07_20.oct | rcalc -e '$1=$1*0.265+$2*0.67+$3*0.065'

150.718

but the measured global horizontal irradiance
(Pyranometer)
is 252.2 w/m^
2

  I calculated this output for the whole year but still the Perez is
significantly underestimating the horizontal irradiance. I should add that
I used gensky to generate the same output and results showed gensky
horizontal irradiance fit well with Pyranometer irradiance. Does anyone
have any idea what is wrong here?

  Thank you all, Ehsan

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

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

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

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

Hello everyone,

While using gendaylit, I receive the following warning message and error in the outputs:

# gendaylit 5 29 12 -L 925.2 249.348 -a 41.8 -o -12.2333
Warning: sun altitude below zero at time step 5 29 12.00, printing error sky
# Local solar time: 20.86
# Solar altitude and azimuth: -13.2 135.6

But if I use a '+' sign before hour then there is no warning message:

# gendaylit 5 29 +12 -L 925.2 249.348 -a 41.8 -o -12.2333
# Local solar time: 12.00
# Solar altitude and azimuth: 69.7 -0.0

Could you please tell me what would be the possible reason for such behaviour? I want to get solar altitude and azimuth angles based on standard time and not on local solar time.

PS: I am using these Windows command prompt to execute gendaylit.

Thanks,

Hemshikha

Hi Hemshikha,

you need to include the site meridian, not just lat/lon:

-m 0 (if your time zone is GMT)

The default is -m 120

[axel@localhost ~]$ gendaylit -defaults
-g 0.200000 # Ground plane reflectance
-t 0.100000 # Atmospheric betaturbidity
-a 37.815214 # Site latitude (degrees)
-o 122.040010 # Site longitude (degrees)
-m 120.000281 # Standard meridian (degrees)

Regards

Axel

···

On 31/10/16 18:48, Saini, H. wrote:

Hello everyone,

While using gendaylit, I receive the following warning message and error in the outputs:

# gendaylit 5 29 12 -L 925.2 249.348 -a 41.8 -o -12.2333
Warning: sun altitude below zero at time step 5 29 12.00, printing error sky
# Local solar time: 20.86
# Solar altitude and azimuth: -13.2 135.6

But if I use a '+' sign before hour then there is no warning message:

# gendaylit 5 29 +12 -L 925.2 249.348 -a 41.8 -o -12.2333
# Local solar time: 12.00
# Solar altitude and azimuth: 69.7 -0.0

Could you please tell me what would be the possible reason for such behaviour? I want to get solar altitude and azimuth angles based on standard time and not on local solar time.

PS: I am using these Windows command prompt to execute gendaylit.

Thanks,

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