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> 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
_______________________________________________
Radiance-dev mailing list
Radiance-dev@radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-dev
