Three-Phase Method - subdivision of window with sensor located close to the window

Hi Anne,

On my computer the text on your charts show up as black squares. But I think I can still provide some relevant advice.

Generally speaking, subdivision of the window for the three phase method is only necessary when there are nearby external obstructions or for intermediary blind positions. But your case is unusual - your sensor point is so very close to the window.

When generating the view matrix we typically use a light material for the window. Direct (deterministic) sampling is used to calculate the window's contribution. The direct sampling algorithm will automatically divide a light source according to the -ds parameter, however the maximum number of divisions is limited to 64 (as determined by the variable MAXSPARTS in source.h). Given the proximity of your sensor to the window I don't think 64 direct samples will accurately map the window's outgoing klems divisions to illuminance contribution at your sensor. Manually subdividing the window is one approach. Though rather than horizontal bands I'd suggest a pattern of squares that is finer near the sensor and corse away from the sensor (see ascii art below). You also want to set -dt 0 and -dc 1.

···

____________________

>__|__|__| |
______|__|__|__|______|
> > >
______|_______|______|

Alternatively you could consider using ambient sampling to sample the window. You could try using a glow material for the window and set -ad 2000 or higher. Roughly half the initial ambient sample rays would hit the window (because your sensor is nearly against the window). -ab can be low and -lw should be less than 1/ad, probably 1/ad^2. I've never tried this, so I don't know how well (or if) it'll work.

If it were me, I'd give the glow material a try. It seems much more elegant and now that I think about it, it might be a better approach for some spaces.

Good luck,
Andy

On Apr 28, 2011, at 8:48 AM, Anne Iversen wrote:

Hi list - Hope you have time to give me some guidance here

My question is if any of you have any recommendations or thoughts on how I should or shouldn't subdivide the window?

Problem:

I have a scene with a sensor located close to the window. The window is placed in y=0.82, and the sensor is located in y=0.84, just behind the window. Due to the sensor location this close to the window I’m thinking I have to subdivide the window to get a correct sensor reading, especially when solar shading is included in my simulations.

I have run simulations for 4 different cases with different subdivisions of the window. The transmission matrix is an .xml file generated with window6 for a clear window. Nothing special here, yet! In further simulations I’ll introduce solar shading.

My simulation results show that the sensor signal differs with the different subdivisions.

You can see the results and subdivision of window in this link:
http://dl.dropbox.com/u/9713279/ThreePhaseMethod_Subdivision.pdf

And my script if necessary, in this link:
http://dl.dropbox.com/u/9713279/threephasemethod.bash

Anne
_______________________________________________
[email protected]

Hi Anne,

I agree that you should try the glow window. If you are using the rsensor program as your script seems to indicate, rays will be distributed over the window independently from how you've defined it. Only the secondary bounces will care if it's a light source or a glow and whether it's subdivided, and those should not matter to the results. This leaves the puzzle of why your output varies so much in the first place.

Have you tried generating hemispherical fisheye views from the sensor position under the different simulation conditions? This is always my favorite way of debugging such problems.

Best,
-Greg

···

From: David Geisler-Moroder <[email protected]>
Date: April 28, 2011 11:24:17 AM PDT

Hi Anne,

give Andy's suggestion using the glow material a try - I usually do that for large windows (i.e. in most cases) to avoid the
subsampling problem of the "window lights". Even if you do not put sensors close to the window, you mostly have walls
somewhere close to the window where the same issue arises.
Manually subdividing is only necessary - as Andy states - if it's needed because of changes in the exterior illumination.

Cheers,
David

Hi Anne,

Hmmm. I didn't notice that you're using rsensor to generate rays. Unfortunately my suggested pattern for subdividing the window is useless. And using glow probably won't make much difference - unless your sensor has a tight and/or peaky sensitivity distribution. Can you share information about the sensors sensitivity? Maybe share the sensor dat file? Also, is your sensor on the ceiling or the window head?

Andy

···

On Apr 28, 2011, at 11:42 AM, Greg Ward wrote:

Hi Anne,

I agree that you should try the glow window. If you are using the rsensor program as your script seems to indicate, rays will be distributed over the window independently from how you've defined it. Only the secondary bounces will care if it's a light source or a glow and whether it's subdivided, and those should not matter to the results. This leaves the puzzle of why your output varies so much in the first place.

Have you tried generating hemispherical fisheye views from the sensor position under the different simulation conditions? This is always my favorite way of debugging such problems.

Best,
-Greg

From: David Geisler-Moroder <[email protected]>
Date: April 28, 2011 11:24:17 AM PDT

Hi Anne,

give Andy's suggestion using the glow material a try - I usually do that for large windows (i.e. in most cases) to avoid the
subsampling problem of the "window lights". Even if you do not put sensors close to the window, you mostly have walls
somewhere close to the window where the same issue arises.
Manually subdividing is only necessary - as Andy states - if it's needed because of changes in the exterior illumination.

Cheers,
David

_______________________________________________
[email protected]

Hi Anne,
Just curious, how do the glow results compare to the light sources? Could you update the graph with the sensor signals using the glow material?
Andy

···

On Apr 29, 2011, at 5:32 AM, Anne Iversen wrote:

Thanks Greg, David and Andy for your replies.
Have run simulations with the glow material and find no significant differences in sensor signal when having no subdivision compared to different subdivisions. So I'll stick to the glow material for my window and simulate without any window subdivision. Elegant ;-).

I have simply changed the window material from light to glow and set the settings as recommended by Andy.

void glow windowlight
0
0
4 1 1 1 0

Best,
Anne

On Thu, Apr 28, 2011 at 9:00 PM, <[email protected]> wrote:
Send Radiance-general mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
[email protected]

You can reach the person managing the list at
[email protected]

than "Re: Contents of Radiance-general digest..."

Today's Topics:

1. Re: Three-Phase Method - subdivision of window with sensor
located close to the window (David Geisler-Moroder)
2. Re: Three-Phase Method - subdivision of window with sensor
located close to the window (Greg Ward)

----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Apr 2011 20:24:17 +0200
From: David Geisler-Moroder <[email protected]>
To: [email protected]
Subject: Re: [Radiance-general] Three-Phase Method - subdivision of
window with sensor located close to the window
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Hi Anne,

give Andy's suggestion using the glow material a try - I usually do that
for large windows (i.e. in most cases) to avoid the
subsampling problem of the "window lights". Even if you do not put
sensors close to the window, you mostly have walls
somewhere close to the window where the same issue arises.
Manually subdividing is only necessary - as Andy states - if it's needed
because of changes in the exterior illumination.

Cheers,
David

Am 28.04.2011 19:38, schrieb Andy McNeil:
> Hi Anne,
>
> On my computer the text on your charts show up as black squares. But
> I think I can still provide some relevant advice.
>
> Generally speaking, subdivision of the window for the three phase
> method is only necessary when there are nearby external obstructions
> or for intermediary blind positions. But your case is unusual - your
> sensor point is so very close to the window.
>
> When generating the view matrix we typically use a light material for
> the window. Direct (deterministic) sampling is used to calculate the
> window's contribution. The direct sampling algorithm will
> automatically divide a light source according to the -ds parameter,
> however the maximum number of divisions is limited to 64 (as
> determined by the variable MAXSPARTS in source.h). Given the
> proximity of your sensor to the window I don't think 64 direct samples
> will accurately map the window's outgoing klems divisions to
> illuminance contribution at your sensor. Manually subdividing the
> window is one approach. Though rather than horizontal bands I'd
> suggest a pattern of squares that is finer near the sensor and corse
> away from the sensor (see ascii art below). You also want to set -dt
> 0 and -dc 1.
> ____________________
> > >__|__|__| |
> >______|__|__|__|______|
> > > > >
> >______|_______|______|
>
> Alternatively you could consider using ambient sampling to sample the
> window. You could try using a glow material for the window and set
> -ad 2000 or higher. Roughly half the initial ambient sample rays
> would hit the window (because your sensor is nearly against the
> window). -ab can be low and -lw should be less than 1/ad, probably
> 1/ad^2. I've never tried this, so I don't know how well (or if)
> it'll work.
>
> If it were me, I'd give the glow material a try. It seems much more
> elegant and now that I think about it, it might be a better approach
> for some spaces.
>
> Good luck,
> Andy
>
>
>
>
> On Apr 28, 2011, at 8:48 AM, Anne Iversen wrote:
>
>> Hi list - Hope you have time to give me some guidance here
>>
>>
>> My question is if any of you have any recommendations or thoughts on
>> how I should or shouldn't subdivide the window?
>>
>>
>> *Problem:*
>>
>> I have a scene with a sensor located close to the window. The window
>> is placed in y=0.82, and the sensor is located in y=0.84, just behind
>> the window. Due to the sensor location this close to the window I?m
>> thinking I have to subdivide the window to get a correct sensor
>>
>>
>> I have run simulations for 4 different cases with different
>> subdivisions of the window. The transmission matrix is an .xml file
>> generated with window6 for a clear window. Nothing special here, yet!
>> In further simulations I?ll introduce solar shading.
>>
>> My simulation results show that the sensor signal differs with the
>> different subdivisions.
>>
>> You can see the results and subdivision of window in this link:
>> http://dl.dropbox.com/u/9713279/ThreePhaseMethod_Subdivision.pdf
>>
>> And my script if necessary, in this link:
>> http://dl.dropbox.com/u/9713279/threephasemethod.bash
>>
>> Anne
>> _______________________________________________
>> [email protected]
>> <mailto:[email protected]>
>
>
> _______________________________________________
> [email protected]

-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Thu, 28 Apr 2011 11:42:03 -0700
From: Greg Ward <[email protected]>
To: Radiance general discussion <[email protected]>
Subject: Re: [Radiance-general] Three-Phase Method - subdivision of
window with sensor located close to the window
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Anne,

I agree that you should try the glow window. If you are using the rsensor program as your script seems to indicate, rays will be distributed over the window independently from how you've defined it. Only the secondary bounces will care if it's a light source or a glow and whether it's subdivided, and those should not matter to the results. This leaves the puzzle of why your output varies so much in the first place.

Have you tried generating hemispherical fisheye views from the sensor position under the different simulation conditions? This is always my favorite way of debugging such problems.

Best,
-Greg

> From: David Geisler-Moroder <[email protected]>
> Date: April 28, 2011 11:24:17 AM PDT
>
> Hi Anne,
>
> give Andy's suggestion using the glow material a try - I usually do that for large windows (i.e. in most cases) to avoid the
> subsampling problem of the "window lights". Even if you do not put sensors close to the window, you mostly have walls
> somewhere close to the window where the same issue arises.
> Manually subdividing is only necessary - as Andy states - if it's needed because of changes in the exterior illumination.
>
> Cheers,
> David

------------------------------

_______________________________________________
[email protected]

End of Radiance-general Digest, Vol 86, Issue 23
************************************************

_______________________________________________
[email protected]

I have included the results from the glow simulations in the document:

http://dl.dropbox.com/u/9713279/ThreePhaseMethod_Subdivision.pdf

(the non-readable legends and axes must be a mac thing...the same happens
when I open the documet on my mac, I can read the graphs nicely in the pdf
on my pc. ...have included some text in the captions, if you want to know
what you are looking at ;-))

I believe this sometimes happens with PDFs produced by Office. And, yes, legends etc. often get 'blacked out' when viewed using either Safari or Preview (similar on iOS). However, they usually render correctly on the Mac if you open the PDFs with Adobe Reader.

J

Hi Anne,

I believe David is correct. I should have looked at your command more closely. The -I+ switch does not belong. If you remove it (or set -I-), then the computed radiance values will be accumulated according to the distributed rays out of rsensor, then split again into Klems direction bins by rtcontrib. The *.vmx files will each contain a single row of 145 RGB coefficients, which processed through dctimestep with the window's BTDF file will ultimately yield a single sensor value at each time step.

I hope this makes sense. I find it a bit confusing, myself!

Best,
-Greg

···

From: David Geisler-Moroder <[email protected]>
Date: May 2, 2011 2:41:44 AM PDT

Hi Anne,

another thing that came to my mind...

You are calling rtcontrib for the VMX using rsensor in your script like that:
rsensor -h -rd 1000 -vf views/luxstat.vf sensors/WattStopper_LS-290C.dat . |\
rtcontrib -c 1000 -f klems_int.cal -bn Nkbins -fo -o results/"\$vmxname"_%s.vmx \
-b kbinS -m windowlight -b kbinS -m windowlightsens \
-I+ -ab 3 -ad 2000 -ds .15 -lw 1e-4 model_vmx.oct

Do you want to obtain the sensor signal split up into the Klems bins?
If yes, I'm not sure if it works like that...

You are using rsensor to generate 1000 rays (i.e. origin and direction) according to the sensor-file.
These points and directions are then given to rtcontrib, where you use -c 1000 to accumulate all
1000 results and -I+ to switch to irradiances.
However, this means that rtcontrib calculates irradiances for 1000 pairs of points and directions as
if it was e.g. a grid for illuminance calculations. So you do not obtain the sensor signal, but a mean

I hope I'm not missing anything...

Cheers,
David

Low resolution sampling of the outgoing window directions will only affect calculations on surfaces near the window. And they should just cause noise that is a fraction of the values from the direct sampling of the window by rsensor. So the only way I can think that glow vs. light would make a sizable difference is if your sensor is somewhat shielded from the window (by sensitivity or by placement) and/or most of the rsensor samples a sent to surfaces near the window ( ie focused sensitivity). Neither of these seem to be the cause though using -I+ would have had the effect of masking the direct contribution from the window in a similar way because rsensor rays that hit the window don't return a direct value but instead start an iluminance calculation on the window.

I'd suggest that while you are running everything again without -I that you also simulate using classic Radiance techniques (ie not the three-phase method).

Andy

···

On Apr 30, 2011, at 6:11 AM, Anne Iversen wrote:

Why do you believe that using glow probably won't make much difference - unless my sensor has a tight and/or peaky sensitivity distribution?