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).
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
-------- Original Message --------
[Radiance-dev] gendaylit 2.3
Mon, 26 Aug 2013 23:09:08 +0100
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.
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 skyfunc2 skybright perezlum.cal010 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 skyfunc2 skybright perezlum.cal010 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 6void light solar 003 0.0 0.0 0.0solar source sun004 -0.890913 -0.454035 0.011245 0.533000 void brightfunc skyfunc2 skybright perezlum.cal010 7.891e-01 2.051e-01 0.636339 -0.630451 0.478351 -0.421145 -0.036172 -0.890913 -0.454035 0.011245But 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 skyfunc2 skybright perezlum.cal010 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. CheersAxel_______________ _________________________ _______ Radiance-dev mailing list