Hey Jack, thanks for this. Good stuff. I am hoping to refactor the mess that is DaylightSim.rb this quarter, to make it more easily maintainable, and one of the things I plan to do at that time is also improve on this gendaylit error handling business!
Rob Guglielmetti National Renewable Energy Laboratory (NREL) Commercial Buildings Research Group 15013 Denver West Parkway MS:RSF202 Golden, CO 80401 303.275.4319 robert.guglielme...@nrel.gov On 10/17/12 12:29 PM, "Jack de Valpine" <je...@visarc.com<mailto:je...@visarc.com>> wrote: Hi Tim, I sent this out earlier and I do not know why it did not get through (perhaps the mail server is choking on my sig). Here is my earlier response to Rob's follow-up. In short you might look at adjusting the time value by +/- 15 minutes. -Jack de Valpine Hey Rob, Just to fill in the details a bit more now. I am largely working from Axel's observations on under what circumstances gendaylit fails. From what I have seen the error conditions are: 1. if the Diffuse Normal Radiation is 0, in which case assume a night time step 2. if the time used results in a solar zenith angle > 90 - this seems to occur at the boundary conditions around sunrise/sunset - this will report an error 3. if the -W parameters are out of bounds for what gendaylit expects at a given time step - this looks like it seg faults To process the weather data, I have been setting the time at 30 minutes less than the hour reported in the weather file. It occurs to me that in the case of (2) it might make sense to continue testing with altered times until a value is reported (just thinking off the cuff here). So for example (in condensed form): The weather file for Boston reports the following for January 1 at 17:00 direct normal irradiance: 7 diffuse horizontal irradiance: 5 if we do: gendaylit 1 1 16.5 -a 42.37 -o 71.02 -m 75 -W 7 5 we will get an error relating to zenith angle > 90 however if we then move back 15 minutes: gendaylit 1 1 16.25 -a 42.37 -o 71.02 -m 75 -W 7 5 we actually get a valid description... Curiously adding 15 minutes to the time step in Tim's case actually results in a sky description: gendaylit 7 19 14.500 -W 924 65 -a 34.3 -o 116.17 -m 120 results in seg fault gendaylit 7 19 14.2500 -W 924 65 -a 34.3 -o 116.17 -m 120 results in error message: sky clearness or sky brightness out of range 12.605739 0.059480 gendaylit 7 19 14.7500 -W 924 65 -a 34.3 -o 116.17 -m 120 results in sky description Note I am picking 15 minutes as the next increment as halving of the 30 minute value. Not really sure what this tells us or how it helps.... It is also not clear to me any issues that might result, eg pros/cons of: 1. gendaylit initially fails so we fall back on gensky 2. gendaylit initially fails so we use a different time value (within the hour of record) to get "good" output 3. gendaylit initially fails so we fall back on the previous hour's value output -Jack On 10/17/2012 2:18 PM, Tim Perry wrote: Thank you, everyone, for the information. It sounds like gendaylit just can't handle some of the sky params and I need to enhance my scripts a bit. I imagine I'll be following Rob's lead. Or perhaps I'll just use his scripts. In that short run, what if I just adjust the diffuse value up from 65 to 65.07. Then I get a valid sky. The change is only 0.1%. Should I reduce the direct to compensate? Or just not worry about it? Thanks, Tim On Wed, Oct 17, 2012 at 7:41 AM, Guglielmetti, Robert <robert.guglielme...@nrel.gov><mailto:robert.guglielme...@nrel.gov> wrote: On 10/16/12 7:56 PM, "Jack de Valpine" <je...@visarc.com<mailto:je...@visarc.com><mailto:je...@visarc.com><mailto:je...@visarc.com>> wrote: Hi Tim, I cannot test this right now, however I do know that it is possible for gendaylit to fail in select conditions. If I recall correctly, one is if the direct normal radiance is zero (not the case here). There are other cases where it fails more dramatically, which is what you are facing I believe. In this case I think that the thing to do is re-use a previous value from the data set (eg the previous hour). Unfortunately, what you really need to do is actually "test" if gendaylit is going to produce valid output prior to actually getting the output. This can be done by evaluating the result of: gendaylit $myArgs > /dev/null 2>&1 which in your case would be gendaylit 7 19 14.500 -W 924 65 -a 34.3 -o 116.17 -m 120 > /dev/null 2>&1 Assuming your are processing a complete weather file then you need to test every time step that is not definitively at night, so that you can catch any time steps that case an error for gendaylit and then do something in those places. This has been a constant headache for us as well, as we are trying to use gendaylit in the OpenStudio annual simulation stuff. We do a test like Jack has illustrated above, again cribbing from Axel's excellent tutorials. We have found that bad sky descriptions can still be written (or nothing), and our test can miss some. The error reporting in gendaylit seems inconsistent. We try to scan for all the warnings/errors we have seen coming from gendaylit like so: gendaylit_command = "gendaylit -ang #{tsSolarAlt} #{tsSolarAzi} -L #{tsDirectNormIllum} #{tsDiffuseHorIllum} 2>&1" tempIO = IO.popen(gendaylit_command) gendaylit_output = tempIO.readlines.to_s tempIO.close tempSky = true if /[wW]arning/.match(gendaylit_output) or /[eE]rror/.match(gendaylit_output) or /valid/.match(gendaylit_output) or /[cC]heck/.match(gendaylit_output) or /skyclearness/.match(gendaylit_output) tempSky = false End …we fall back on gensky if found. Andy McNeil proposes scanning for a really tiny file (one of the failure modes for gendaylit is it writes a blank file with no errors generated). I implemented that in Ruby with the tempfile class, but obviously I did a poor job because the tempfiles were not being properly killed, so I took that out for now. But I do need to beef up this error checking as we'd prefer to use gendaylit. - Rob _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org<mailto:Radiance-dev@radiance-online.org>http://www.radiance-online.org/mailman/listinfo/radiance-dev _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org<mailto: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
