this in your talk. The version in HEAD seems to be the Fraunhofer one. Where
is the one based on Ian Ashdown's implementation? I'm a little confused...
···
-----Original Message-----
From: [email protected]
[mailto:[email protected]]
Sent: August-27-13 12:00 PM
To: [email protected]
Subject: Radiance-dev Digest, Vol 88, Issue 3
Send Radiance-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.radiance-online.org/mailman/listinfo/radiance-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Radiance-dev digest..."
Today's Topics:
1. gendaylit 2.3 (Axel Jacobs)
2. Re: gendaylit 2.3 (Rob Guglielmetti)
3. Re: gendaylit 2.3 (Jan Wienold)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Aug 2013 23:09:08 +0100
From: Axel Jacobs <[email protected]>
To: [email protected]
Subject: [Radiance-dev] gendaylit 2.3
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dear all,
it appears you've had three very interesting and productive days at the WS.
I am only just catching up with the presentations and videos.
Amongst the many cool topics, the new v2.3 of gendaylit caught my attention.
As some of you might recall, I ran the old gendaylit (don't remember what
version) against all EPW files that were then available on the E+ web site
when I worked on my rtcontrib tutorial.
http://www.jaloxa.eu/resources/radiance/documentation/docs/gendaylit_epw_err
ors.html
If there had been an executive summary, it would have read "it's a right old
mess". There are big problems with the quality of the weather data.
I'm re-running this against v2.3 and the latest weather files. It's too soon
to present any detailed analysis yet (it's taking for ages on my computer),
but please find below some observations:
a) Below is from 2_asia_wmo_region_2/CHN_Anhui.Tunxi.585310_CSWD.epw
Classic (no -i):
# gendaylit 1 2 17.5 -a 29.72 -o -118.28 -m -120.0 -W 0 6
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 0.00 0.00 0.000 0.000 0.000 0.000 0.000 -0.000000 -1.000000 0.000000
This is a dark sky without sun. Return code of 1, but nothing on stderr.
New and improved (-i 60):
# gendaylit 1 2 17.5 -a 29.72 -o -118.28 -m -120.0 -i 60 -W 0 6
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 0.00 0.00 0.000 0.000 0.000 0.000 0.000 -0.000000 -1.000000 0.000000
Still a dark sky. Return code of 1, but nothing on stderr.
Maybe the sunset is not within +/- 30 minutes of 17:30?
# gendaylit 1 2 17.2 -a 29.72 -o -118.28 -m -120.0 -W 0 6
void light solar
0
0
3 0.0 0.0 0.0
solar source sun
0
0
4 -0.890913 -0.454035 0.011245 0.533000
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 7.891e-01 2.051e-01 0.636339 -0.630451 0.478351 -0.421145 -0.036172
-0.890913 -0.454035 0.011245
But it is! Sometime between 17.2 and 17.3 hrs
b) The usage info (eg when run without options and params) does not show -i
and -s.
c) The old gendaylit used to produce a header just like gensky, with sun
alti, azi, groundamb etc in it. This was extremely helpful.
d) The new -i option now creates a warning message, and an exit status of 1
if the new algorithm kicks in. Is this really a good idea? After all, by
setting -i, we have actually asked gendaylit to do exactly this.
Would it not be better to have a few extra header lines with corrected time
and solar position (possibly even sunrise/sunset for that day)?
e) Greg, could you elaborate why we have two gendaylit now? You mentioned
this in your talk. The version in HEAD seems to be the Fraunhofer one. Where
is the one based on Ian Ashdown's implementation?
I'm a little confused...
f) here is quite a common error with weather files - Positive sun alti, but
no irradiance:
# gendaylit 9 6 7.5 -a -39.01 -o -174.18 -m -180.0 -i 60 -W 0 0
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 0.00 0.00 0.000 0.000 0.000 0.000 0.000 0.960801 0.245763 0.128307
Return code is 1, stderr is
"Solar position corrected at 9 6 7.500
ERROR: Model parameters out of range, skyclearness = -nan"
gensky tells me the alti is 9.0 degrees. This is in New Zealand.
This is not a gendaylit bug, but rather a problem with the Perez model,
which is only calibrated against Berkeley, CA and Watford, UK data. Is there
something that can be done about it? There are quite a few such problems in
many of the weather files.
Thanks for your thoughts. I'll report back when I have more results.
Cheers
Axel
------------------------------
Message: 2
Date: Mon, 26 Aug 2013 17:06:19 -0600
From: Rob Guglielmetti <[email protected]>
To: code development <[email protected]>
Subject: Re: [Radiance-dev] gendaylit 2.3
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Axel!
I have but a sec, and there rare others better equipped mentally to answer
most of your questions, but really quick:
On Aug 26, 2013, at 4:09 PM, Axel Jacobs <[email protected]> wrote:
e) Greg, could you elaborate why we have two gendaylit now? You mentioned
this in your talk. The version in HEAD seems to be the Fraunhofer one. Where
is the one based on Ian Ashdown's implementation? I'm a little confused...
There still is only one gendaylit, and it is the Fraunhofer code. The other
thing we have is Ian Ashdown's Perez sky implementation that Greg used in
the new gendaymtx program to generate (usually) annual sky matrices based on
the Perez model.
- Rob
------------------------------
Message: 3
Date: Tue, 27 Aug 2013 12:23:27 -0400
From: Jan Wienold <[email protected]>
To: code development <[email protected]>
Cc: Wendelin Sprenger <[email protected]>
Subject: Re: [Radiance-dev] gendaylit 2.3
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Axel,
thanks for testing out the new version - this is very helpful. And sorry if
there are still some small bugs in it, we will fix it. I also think we will
consider your suggestions b), c) and d).
e) was answered by rob.
I forward this email to my colleague Wendelin, who hasn't subscribed to the
dev list I guess.
We will come back to you soon!
Cheers,
Jan
On 08/26/2013 06:09 PM, Axel Jacobs wrote:
Dear all,
it appears you've had three very interesting and productive days at
the WS. I am only just catching up with the presentations and videos.
Amongst the many cool topics, the new v2.3 of gendaylit caught my
attention.
As some of you might recall, I ran the old gendaylit (don't remember
what version) against all EPW files that were then available on the E+
web site when I worked on my rtcontrib tutorial.
http://www.jaloxa.eu/resources/radiance/documentation/docs/gendaylit_e
pw_errors.html
If there had been an executive summary, it would have read "it's a
right old mess". There are big problems with the quality of the
weather data.
I'm re-running this against v2.3 and the latest weather files. It's
too soon to present any detailed analysis yet (it's taking for ages on
my computer), but please find below some observations:
a) Below is from 2_asia_wmo_region_2/CHN_Anhui.Tunxi.585310_CSWD.epw
Classic (no -i):
# gendaylit 1 2 17.5 -a 29.72 -o -118.28 -m -120.0 -W 0 6
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 0.00 0.00 0.000 0.000 0.000 0.000 0.000 -0.000000 -1.000000
0.000000
This is a dark sky without sun. Return code of 1, but nothing on stderr.
New and improved (-i 60):
# gendaylit 1 2 17.5 -a 29.72 -o -118.28 -m -120.0 -i 60 -W 0 6
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 0.00 0.00 0.000 0.000 0.000 0.000 0.000 -0.000000 -1.000000
0.000000
Still a dark sky. Return code of 1, but nothing on stderr.
Maybe the sunset is not within +/- 30 minutes of 17:30?
# gendaylit 1 2 17.2 -a 29.72 -o -118.28 -m -120.0 -W 0 6
void light solar
0
0
3 0.0 0.0 0.0
solar source sun
0
0
4 -0.890913 -0.454035 0.011245 0.533000
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 7.891e-01 2.051e-01 0.636339 -0.630451 0.478351 -0.421145 -0.036172
-0.890913 -0.454035 0.011245
But it is! Sometime between 17.2 and 17.3 hrs
b) The usage info (eg when run without options and params) does not
show -i and -s.
c) The old gendaylit used to produce a header just like gensky, with
sun alti, azi, groundamb etc in it. This was extremely helpful.
d) The new -i option now creates a warning message, and an exit status
of 1 if the new algorithm kicks in. Is this really a good idea? After
all, by setting -i, we have actually asked gendaylit to do exactly
this. Would it not be better to have a few extra header lines with
corrected time and solar position (possibly even sunrise/sunset for
that day)?
e) Greg, could you elaborate why we have two gendaylit now? You
mentioned this in your talk. The version in HEAD seems to be the
Fraunhofer one. Where is the one based on Ian Ashdown's
implementation? I'm a little confused...
f) here is quite a common error with weather files - Positive sun
alti, but no irradiance:
# gendaylit 9 6 7.5 -a -39.01 -o -174.18 -m -180.0 -i 60 -W 0 0
void brightfunc skyfunc
2 skybright perezlum.cal
0
10 0.00 0.00 0.000 0.000 0.000 0.000 0.000 0.960801 0.245763
0.128307
Return code is 1, stderr is
"Solar position corrected at 9 6 7.500
ERROR: Model parameters out of range, skyclearness = -nan"
gensky tells me the alti is 9.0 degrees. This is in New Zealand.
This is not a gendaylit bug, but rather a problem with the Perez
model, which is only calibrated against Berkeley, CA and Watford, UK
data. Is there something that can be done about it? There are quite a
few such problems in many of the weather files.
Thanks for your thoughts. I'll report back when I have more results.
Cheers
Axel
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
--
Dr.-Ing. Jan Wienold
Head of Team Passive Systems and Daylighting Fraunhofer-Institut f?r Solare
Energiesysteme Thermal Systems and Buildings Heidenhofstr. 2, 79110
Freiburg, Germany
Phone: +49(0)761 4588 5133 Fax:+49(0)761 4588 9133
[email protected] http://www.ise.fraunhofer.de
In office:
Mo,Tue: 8:30-18:00
We,Thu: 8:30-16:00
Fr: 8:30-15:30
------------------------------
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
End of Radiance-dev Digest, Vol 88, Issue 3
*******************************************