Hi Anne, Lars, everyone,
Fun topic! Replies within...
1)
What I get out of rsensor can be illuminance readings for the specified
photocell?
The following command would generate the illuminance-level on the sensor,
right?
rsensor -ab XX -i [sensor view] sensor_file scene.oct > illsensor.dat
Actually, rsensor computes photosensor response on the sensor -- which WOULD
be illuminance assuming the sensor's response was a perfect cosine one, but
the final output of rsensor ultimately is photosensor response. So your
command above would send the sensor response to STDOUT.
2)
From Axel Jacobs tutorial on rtcontrib I can see how I can obtain illuminance
readings from photocells defined as points - but how should I do it if I am
not interested in the point illuminance reading, but interested in the
illuminance level falling onto the sensor that doesn't see an hemisphere?
Can I somehow replace the
$ cat workingplane_photocell.pts | rtcontrib .........
with
$ cat [sensor view] sensor_file....| rtcontrib...??
Lars proposes an image based approach to evaluating what the sensor "sees"
and integrating a weighted response. This in effect is what psens (Chas
Ehrlich's project) does, on a single image. This is the tool Zack Rogers
used in SPOT's initial versions, and it was SPOT that led to the development
of rsensor in the first place. What you are trying to do above is to apply
the daylight coefficient approach to deriving the photosensor response, and
I think it's no secret to anyone watching this mailing list over the last
year or so that this is a subject of great interest to us all and some of us
are working on this to some degree. The reason for the interest is that with
daylight coefficients, we can do annual simulations with hourly resolution
(and even incorporate occupant response (blinds, etc) and complex
fenestration systems), in a reasonable timeframe.
The promise here is being able to leverage new tools in the Radiance toolkit
to not only calculate annual daylight availability and quality metrics, but
to carry that capability through to the ever-crucial follow-through on the
electric lighting side -- the daylight-responsive lighting control response
-- and to study this at an annual/hourly resolution. This would allow us to
inform whole building energy simulation tools and really start to understand
the energy impacts of daylighting in a holistic way.
We at last have tools to get us partway there. These would be rtcontrib,
genskyvec, and dctimestep. With these we can compute DCs for task plane
illuminance, but also -- critically -- sensor points on the ceiling or some
arbitrary location/aiming. But we still want to be able to weight the
contributions by the photosensor response. For this, I could imagine a cal
file inserts itself into this workflow, maybe dctimestep accepts an
additional argument for a cal file and there's a "signal" option for passing
all this to rsensor. (?)
Kung Fu Feature Request:
OR, as we gather up all the DCs and weight them by the sky luminance, could
we ALSO weight them by photosensor response, BEFORE summing and computing a
signal? My sense is that this is not possible but I don't fully understand
all the ray accounting that is possible in rtcontrib. Perhaps this could be
a new feature? (???) (!!!)
We are working on rtcontrib-based tools here at NREL and are basically at
this very crossroads. I believe others out there are "there" too, and I
wanted to file this reply since it will have to serve as a proxy for my
attendance at the Workshop next week. =(
Very exciting times.
Rob Guglielmetti IESNA, LEED AP
Building Energy Efficiency Engineer
National Renewable Energy Laboratory
1617 Cole Blvd, MS-5202
Golden, CO 80401-3393
T. 303.275.4319
F. 303.384.7540
E. [email protected]
···
On 9/15/10 12:17 PM, "Anne Iversen" <[email protected]> wrote:
