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!
···
On 10/17/12 12:29 PM, "Jack de Valpine" <[email protected]<mailto:[email protected]>> 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 <[email protected]><mailto:[email protected]> wrote:
On 10/16/12 7:56 PM, "Jack de Valpine" <[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>http://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________
Radiance-dev mailing list
[email protected]<mailto:[email protected]>http://www.radiance-online.org/mailman/listinfo/radiance-dev