Dear all,
I have updated the gendaylit 2.3 code according to Axel's comments (thanks a lot!) and have sent him the code some minutes ago. If anybody else would like to test the new code before it is added to the HEAD release, please contact me, and I will send you the source code (the file is too large for this e-mail distribution list).
Cheers,
Wendelin
__________ _________________________
Mag.rer.nat. Wendelin Sprenger
Division Thermal Systems and Buildings
Fraunhofer Institute for Solar Energy Systems ISE
Heidenhofstr. 2, 79110 Freiburg, Germany
Phone: +49 (0) 7 61/ 45 88-57 45
wendelin.spren...@ise.fraunhofer.de
http://www.ise.fraunhofer.de
-
-------- Original Message --------
| Subject: | [Radiance-dev] gendaylit 2.3 |
|---|---|
| Resent-To: | wien...@ise.fraunhofer.de |
| Date: | Mon, 26 Aug 2013 23:09:08 +0100 |
| From: | Axel Jacobs <jacobs.a...@gmail.com> |
| Reply-To: | code development <radiance-dev@radiance-online.org> |
| To: | radiance-dev@radiance-online.org |
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 _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
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
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 _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
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
