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> wrote: > On 10/16/12 7:56 PM, "Jack de Valpine" > <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 > 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
