# possible inconsistency of bin numbers between BSDF and kelms_int.cal

Hi all:

In the Klems_init.cal file, for south window (using kbinS), the Klems
coordinate is defined as:

z+: pointing to inside (that is, (0,1, 0) )
x+: pointing to West ( that is (-1, 0, 0) )
y+: pointing to Up (0,0,1)

This coordinate is consistent with the Klems coordinate system used in
WINDOW 6 (see this: https://dl.dropbox.com/u/15562376/coordinate.jpg). In
the figure, Klems coordinate system defines: x or xr points to (-1, 0, 0)
and y or yr points to (0, 0, 1).

However, if using this command to calculate view matrix:

\$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b *kbinS* -bn Nkbins -m
window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

where, kbinS defines z axis in the Klems coordinate system as (0 1 0), that
is, pointing to room interior.

Thus, the bin number calculated by Klems_init.cal is actually based on z
hemisphere <https://dl.dropbox.com/u/15562376/coordinate.jpg> (the
hemisphere protrudes towards room). the bin number corresponds with
"Transmittance Front" in BSDF xml file. For example, ray direction (-1, -1,
0) (backward, ray travels from inside to outside room) hits the bin
58<https://dl.dropbox.com/u/15562376/bin.jpg>
defined in z hemisphere because the hemisphere protrudes towards (0 1 0).
But ray direction (-1 -1 0) hits bin
46<https://dl.dropbox.com/u/15562376/bin.jpg> defined in
z reverse (i.e., zr) coordinate because the hemisphere protrudes towards (0
-1 0) (towards outside).

When calculating Daylighting Matrix, it still uses Klems_init.cal and
kbinS, that is, z hemisphere coordinate system, therefore, Radiance seems
needing to use "Transmission Front", which is defined in z hemisphere. But
currently Radiance uses "Transmission Back" (from inside to outside), which
defined in zr hemisphere,

So, should we need to

(a) use "*kbinN*" (defining z axis of Klems coordinate towards (0 -1 0) )
and "Transmission Back" for south window, or
(b) use "Transmission Front" and *kbinS*?

Thank you !

Jia

···

On Sat, Oct 20, 2012 at 8:11 AM, Jia Hu <hujia06@gmail.com> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
\$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins -m
window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the bin
number, the bin number is about #57 (I did it manually).

seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Jia

search "transmission back" and "transmission front" in the code and find
"Transmission Front" is more likely used according to the code. The
following two code snippets from bsdf_m.c and bsdf.c shows "Transmission
Front" data will be loaded or preferred ?

Another issue, I remember Greg mention that even if only "Transmission
Front" is present, the BSDF library in Radiance can still computer
here<https://dl.dropbox.com/u/15562376/test_10_21.zip>)
did not show that. If you change "Transmission Back" in the .xml file to
"Transmission Front". The results will be zero.

*// ray/src/common/bsdf_m.c*
/*
* Remember that front and back are reversed from WINDOW 6 orientations
* *Favor their "Front" (incoming light) since that's more often valid*
*/
tfront = !strcasecmp(sdata, "Transmission Back");
if (!strcasecmp(sdata, "Transmission Front") ||
tfront & (sd->tf == NULL)) {
if (sd->tf != NULL)
SDfreeSpectralDF(sd->tf);
if ((sd->tf = SDnewSpectralDF(1)) == NULL)
return RC_MEMERR;
df = sd->tf;

*// ray/src/common/bsdf.c*

for (wld = ezxml_child(wtl, "WavelengthData");
wld != NULL; wld = wld->next) {
if (strcasecmp(ezxml_txt(ezxml_child(wld,"Wavelength")),
"Visible"))
continue;
for (wdb = ezxml_child(wld, "WavelengthDataBlock");
wdb != NULL; wdb = wdb->next)
if (!strcasecmp(ezxml_txt(ezxml_child(wdb,
*"Transmission Front"))*
break;
if (wdb != NULL) { */* load front BTDF */*
break; /* ignore the rest */
}
}

Thanks,

Jia

···

On Sat, Oct 20, 2012 at 4:01 PM, Jia Hu <hujia06@gmail.com> wrote:

Hi all:

In the Klems_init.cal file, for south window (using kbinS), the Klems
coordinate is defined as:

z+: pointing to inside (that is, (0,1, 0) )
x+: pointing to West ( that is (-1, 0, 0) )
y+: pointing to Up (0,0,1)

This coordinate is consistent with the Klems coordinate system used in
WINDOW 6 (see this: https://dl.dropbox.com/u/15562376/coordinate.jpg). In
the figure, Klems coordinate system defines: x or xr points to (-1, 0, 0)
and y or yr points to (0, 0, 1).

However, if using this command to calculate view matrix:

\$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b *kbinS* -bn Nkbins
-m window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

where, kbinS defines z axis in the Klems coordinate system as (0 1 0),
that is, pointing to room interior.

Thus, the bin number calculated by Klems_init.cal is actually based on z
hemisphere <https://dl.dropbox.com/u/15562376/coordinate.jpg> (the
hemisphere protrudes towards room). the bin number corresponds with
"Transmittance Front" in BSDF xml file. For example, ray direction (-1, -1,
0) (backward, ray travels from inside to outside room) hits the bin 58<https://dl.dropbox.com/u/15562376/bin.jpg>
defined in z hemisphere because the hemisphere protrudes towards (0 1 0).
But ray direction (-1 -1 0) hits bin 46<https://dl.dropbox.com/u/15562376/bin.jpg> defined in
z reverse (i.e., zr) coordinate because the hemisphere protrudes towards (0
-1 0) (towards outside).

When calculating Daylighting Matrix, it still uses Klems_init.cal and
kbinS, that is, z hemisphere coordinate system, therefore, Radiance seems
needing to use "Transmission Front", which is defined in z hemisphere. But
currently Radiance uses "Transmission Back" (from inside to outside), which
defined in zr hemisphere,

So, should we need to

(a) use "*kbinN*" (defining z axis of Klems coordinate towards (0 -1 0)
) and "Transmission Back" for south window, or
(b) use "Transmission Front" and *kbinS*?

Thank you !

Jia

On Sat, Oct 20, 2012 at 8:11 AM, Jia Hu <hujia06@gmail.com> wrote:

Hi all:

I have a question about the bin number.

To calculate view matrix: (south-facing window)
\$ rtcontrib < test.pts -f klems_int.cal -bn Nkbins -b kbinS -bn Nkbins -m
window_mat -I+ -ab 3 -ad 2000 -lw 1e-4 interior.oct > south.vmx

kbinS uses the (0, 1, 0) as normal (pointing to inside room).

For a ray direction (-1, -1, 0), using klems_int.cal to calculate the bin
number, the bin number is about #57 (I did it manually).

seems use "z" hemisphere (see this figure:
https://dl.dropbox.com/u/15562376/coordinate.jpg). From the figure, we
can see "z" hemisphere points to the room (that is, the hemisphere is
located in the room) "zr" (z reverse) hemisphere is towards outside (the
hemisphere is outside the room).

The possible inconsistency is:

(1) Klems_int.cal uses "z" hemisphere to calculate the bin number, for
example, for ray direction (-1, -1, 0), the bin number is #57 for "z"
hemisphere coordinate. (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg)

(2) The "Transmission Back" data in the BSDF .XML is used in the three
and thus the calculation is based on "zr" (z reverse) hemisphere , for ray
direction (-1, -1, 0), the bin number is about #69 according to the "z
reverse" hemisphere coordinate (see this figure:
https://dl.dropbox.com/u/15562376/bin.jpg).

So my questions are:

(a) Given the ray direction, which hemisphere ( "z" or "zr" ) does
"Klems_init.cal" use?

(b) whether the bin numbers (for the same ray direction) between
"Klems_int.cal" and BSDF .xml are inconsistent or not?

(c) if they are using different bin numbers, how to handle ViewMatrix *
BSDF in the calculation?

Jia

Hi Jia,

There was a bug in the recently-added reciprocity calculation in dctimestep, which I hope I have now corrected. Please try this again with the copy of dctimestep.c from the current HEAD.

Thanks for pointing out the problem.

Best,
-Greg

···

From: Jia Hu <hujia06@gmail.com>
Date: October 22, 2012 10:28:52 AM PDT

Hi Andy:

Yes. But currently the fact is that if the back transmission data is missing, the results are zero even if there are front transmission data. That is why I am confused.

Thanks,

Jia

On Mon, Oct 22, 2012 at 12:50 PM, Andrew McNeil <amcneil@lbl.gov> wrote:
dctimestep originally used just the front transmission data, and if front transmission data were missing the result was zero. I think Greg has recently made changes so that it can us back transmission too. Try with the HEAD.

Andy

Yes, that's correct. Reciprocity means that you can reverse the direction for a BTDF if you manage all of the angles correctly, which I wasn't doing before.

Cheers,
-Greg

···

From: Jia Hu <hujia06@gmail.com>
Date: October 23, 2012 8:45:32 PM PDT

Hi Greg,

Thanks for your updating! I looked at the code, which seems to prefer "Front Transmission" (WINDOW 6 convention) data and if it is NULL, then the back transmission data will be used?

Thank you !

Jia

On Tue, Oct 23, 2012 at 6:28 PM, Greg Ward <gregoryjward@gmail.com> wrote:
Hi Jia,

There was a bug in the recently-added reciprocity calculation in dctimestep, which I hope I have now corrected. Please try this again with the copy of dctimestep.c from the current HEAD.

Thanks for pointing out the problem.

Best,
-Greg

From: Jia Hu <hujia06@gmail.com>
Date: October 22, 2012 10:28:52 AM PDT

Hi Andy:

Yes. But currently the fact is that if the back transmission data is missing, the results are zero even if there are front transmission data. That is why I am confused.

Thanks,

Jia

On Mon, Oct 22, 2012 at 12:50 PM, Andrew McNeil <amcneil@lbl.gov> wrote:
dctimestep originally used just the front transmission data, and if front transmission data were missing the result was zero. I think Greg has recently made changes so that it can us back transmission too. Try with the HEAD.

Andy

_______________________________________________