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
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
On 10/17/2012 10:41 AM, Guglielmetti, Robert wrote:
On 10/16/12 7:56 PM, "Jack de Valpine"
<[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]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev
