Two windows different directions Three Phase simulation

radiance-general
1

Hello everyone,

I am working through re-simulating existing radiance models that were created in another programme and wanted to check if I am using the right method.

The files that I have received are 1 radiance model, 2 material files, and a range of bsdf files. (There are no window glow files for creating a view matrix or sky.rad files). The model has two windows, one faces north and one south and having these two windows is tripping me up a bit.

So overall, I have to create one sky matrix, two view matrices and two daylight matrices? Is this correct?

To make the view matrix I am using the command:
rcontrib -f klems_int.cal -bn Nkbins -fo -o results\photocells_%s.vmx -b kbinS -m windowsouth -b kbinN -m windownorth -I+ -ab 12 -ad 5000 -lw 2e-5 model2windows.oct < points.pts

in which %s should generate two files, but when I run it only generates one. Because of this I ran the command twice – one for the north window and one for the south window.

To make the daylight matrix for each window I used two commands to make each matrix:
rfluxmtx north.rad sky.rad material_detailed.rad materialsAliasesDetailed.rad radmodel.rad > north_dmx.dmx

rfluxmtx south.rad sky.rad material_detailed.rad materialsAliasesDetailed.rad radmodel.rad > south_dmx.dmx

Then I combine the matrices for the north window together and then south window together and then add together?

I would also like to know whether the window glow that needs to be inwards facing to create a view matrix can be in the same plane as the windows in the radiance model or if I can have it a couple millimetres in front of the radiance model window. It will mean I have two material directly on each other.

Any clarifications/comments would be very much appreciated.

Many thanks,
Sandi

2

Hi Sandi,

I'm not spotting anything obvious wrong with your Radiance commands. I would also expect your first rcontrib command to generate two view matrix files. The "klems_int.cal" file has been superseded in recent years by "klems_full.cal", which should have the same functionality in this application. Which version of Radiance are you using? (I.e., what does "rcontrib -version" say?) If you are not on 5.1, you might download the latest installer from NREL.

Are your window surface normals both facing into the room, and are windowsouth and windownorth defined as "glow" or "light" materials?

To combine the north and south window contributions, you want to run dctimestep on each, combining your sky matrix or vector with the appropriate BTDF per window to obtain the partial irradiance values at your sensor points. These may then be added together and converted to illuminance using rmtxop. If you are having trouble with this part, send the list of commands and file names you have working, and we can put together the final bits.

Are you working from Sarith's tutorial <https://www.radiance-online.org/learning/tutorials/matrix-based-methods> ? This is the most comprehensive directions we have available.

Best,
-Greg

¡¡¡

From: Sandi Sirikhanchai <[email protected]>
Date: January 22, 2018 3:14:41 PM PST

Hello everyone,

I am working through re-simulating existing radiance models that were created in another programme and wanted to check if I am using the right method.

The files that I have received are 1 radiance model, 2 material files, and a range of bsdf files. (There are no window glow files for creating a view matrix or sky.rad files). The model has two windows, one faces north and one south and having these two windows is tripping me up a bit.

So overall, I have to create one sky matrix, two view matrices and two daylight matrices? Is this correct?

To make the view matrix I am using the command:
rcontrib -f klems_int.cal -bn Nkbins -fo -o results\photocells_%s.vmx -b kbinS -m windowsouth -b kbinN -m windownorth -I+ -ab 12 -ad 5000 -lw 2e-5 model2windows.oct < points.pts

in which %s should generate two files, but when I run it only generates one. Because of this I ran the command twice – one for the north window and one for the south window.

To make the daylight matrix for each window I used two commands to make each matrix:
rfluxmtx north.rad sky.rad material_detailed.rad materialsAliasesDetailed.rad radmodel.rad > north_dmx.dmx

rfluxmtx south.rad sky.rad material_detailed.rad materialsAliasesDetailed.rad radmodel.rad > south_dmx.dmx

Then I combine the matrices for the north window together and then south window together and then add together?

I would also like to know whether the window glow that needs to be inwards facing to create a view matrix can be in the same plane as the windows in the radiance model or if I can have it a couple millimetres in front of the radiance model window. It will mean I have two material directly on each other.

Any clarifications/comments would be very much appreciated.

Many thanks,
Sandi

3

P.S. Forgot to answer your final question. You can place your receiver surface slightly in front of your window -- you are right that you don't want it in the same plane as another surface with a different material. This would definitely mess things up. You can re-use the same inward-facing surface as used for the view matrix receiver as a sender in the rfluxmtx command, and the material type will be ignored. Having this surface a little inside the window will include the window in the daylight matrix. If you want its influence in the view matrix, you can put your glow/light surface just outside the window, still with its surface normal facing into the room. This would be appropriate if you wanted to use a BTDF for an exterior shading system, for example.

4

Hi Greg,

I am using 5.2, I will try with “klems_full.cal” and the windows are defined as “glow”.

I will definitely give the multiplication and addition a good go myself first but thank you for letting me know.

Yes, I am going between Sarith’s tutorial and Andy’s gitbook tutorial.

Your explanation to my final questions is incredibly helpful!

In regards to the multiplication of matrices, I am just testing with one window at the moment and I have an error that says “unexpected column count in header”.

The view matrix has 13 rows and 145 columns

The daylight matrix has 145 rows and 2306 columns

The sky matrix has 146 rows and 8760 columns (but there is only 3 columns (RGB) and many many rows)

And the BTDF is in its own different format.

Should the sky matrix say 146? Or 145? My command to create a smx is: “gendaymtx albany.wea > albany.smx”.

Thank you for your help.

Kind regards,

Sandi

¡¡¡

________________________________
From: Gregory J. Ward <[email protected]>
Sent: Tuesday, January 23, 2018 4:20:26 PM
To: Radiance general discussion
Subject: Re: [Radiance-general] Two windows different directions Three Phase simulation

P.S. Forgot to answer your final question. You can place your receiver surface slightly in front of your window -- you are right that you don't want it in the same plane as another surface with a different material. This would definitely mess things up. You can re-use the same inward-facing surface as used for the view matrix receiver as a sender in the rfluxmtx command, and the material type will be ignored. Having this surface a little inside the window will include the window in the daylight matrix. If you want its influence in the view matrix, you can put your glow/light surface just outside the window, still with its surface normal facing into the room. This would be appropriate if you wanted to use a BTDF for an exterior shading system, for example.
_______________________________________________
Radiance-general mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/radiance-general

5

Hi Sandi,

The output of gendaymtx has 146 columns because the first column corresponds to the ground plane, and this is needed for a full calculation. However, you need to create your daylight matrix in the right way to make use of this. I believe this is explained in Sarith's tutorial, and also in my 2013 rfluxmtx introduction, below. Pay special attention to slide 42:

  https://www.radiance-online.org/community/workshops/2013-golden-co/Ward-RadianceImprovements.pdf

It can also help to give a -y option in your view matrix calculation, corresponding to the number of sensor points (-y 13). I don't think it's required the way you are doing things, but rmtxop (for example) requires the number of rows and columns to be spelled out in the header. Note that this overrides the actual line breaks in the file, making files like the output of gendaymtx a little more readable. (8760x3 columns are a bit much for some line-based editors.)

Cheers,
-Greg

¡¡¡

From: Sandi Sirikhanchai <[email protected]>
Date: January 22, 2018 11:32:50 PM PST

Hi Greg,

I am using 5.2, I will try with “klems_full.cal” and the windows are defined as “glow”.

I will definitely give the multiplication and addition a good go myself first but thank you for letting me know.

Yes, I am going between Sarith’s tutorial and Andy’s gitbook tutorial.

Your explanation to my final questions is incredibly helpful!

In regards to the multiplication of matrices, I am just testing with one window at the moment and I have an error that says “unexpected column count in header”.
The view matrix has 13 rows and 145 columns
The daylight matrix has 145 rows and 2306 columns
The sky matrix has 146 rows and 8760 columns (but there is only 3 columns (RGB) and many many rows)
And the BTDF is in its own different format.

Should the sky matrix say 146? Or 145? My command to create a smx is: “gendaymtx albany.wea > albany.smx”.

Thank you for your help.

Kind regards,
Sandi

From: Gregory J. Ward <[email protected]>
Sent: Tuesday, January 23, 2018 4:20:26 PM

P.S. Forgot to answer your final question. You can place your receiver surface slightly in front of your window -- you are right that you don't want it in the same plane as another surface with a different material. This would definitely mess things up. You can re-use the same inward-facing surface as used for the view matrix receiver as a sender in the rfluxmtx command, and the material type will be ignored. Having this surface a little inside the window will include the window in the daylight matrix. If you want its influence in the view matrix, you can put your glow/light surface just outside the window, still with its surface normal facing into the room. This would be appropriate if you wanted to use a BTDF for an exterior shading system, for example.
_______________________________________________

6

Thanks Greg,

I am going through Sarith’s Tutorial at the moment trying to work out what might be done incorrectly. The link you pasted only has 20 slides and doesn’t have much introduction on rfluxmtx.

Many thanks,
Sandi

¡¡¡

From: Greg Ward<mailto:[email protected]>
Sent: Wednesday, 24 January 2018 6:31 AM
To: Radiance general discussion<mailto:[email protected]>
Subject: Re: [Radiance-general] Two windows different directions Three Phase simulation

Hi Sandi,

The output of gendaymtx has 146 columns because the first column corresponds to the ground plane, and this is needed for a full calculation. However, you need to create your daylight matrix in the right way to make use of this. I believe this is explained in Sarith's tutorial, and also in my 2013 rfluxmtx introduction, below. Pay special attention to slide 42:

It can also help to give a -y option in your view matrix calculation, corresponding to the number of sensor points (-y 13). I don't think it's required the way you are doing things, but rmtxop (for example) requires the number of rows and columns to be spelled out in the header. Note that this overrides the actual line breaks in the file, making files like the output of gendaymtx a little more readable. (8760x3 columns are a bit much for some line-based editors.)

Cheers,
-Greg

From: Sandi Sirikhanchai <[email protected]<mailto:[email protected]>>

Date: January 22, 2018 11:32:50 PM PST

Hi Greg,

I am using 5.2, I will try with “klems_full.cal” and the windows are defined as “glow”.

I will definitely give the multiplication and addition a good go myself first but thank you for letting me know.

Yes, I am going between Sarith’s tutorial and Andy’s gitbook tutorial.

Your explanation to my final questions is incredibly helpful!

In regards to the multiplication of matrices, I am just testing with one window at the moment and I have an error that says “unexpected column count in header”.

The view matrix has 13 rows and 145 columns

The daylight matrix has 145 rows and 2306 columns

The sky matrix has 146 rows and 8760 columns (but there is only 3 columns (RGB) and many many rows)

And the BTDF is in its own different format.

Should the sky matrix say 146? Or 145? My command to create a smx is: “gendaymtx albany.wea > albany.smx”.

Thank you for your help.

Kind regards,

Sandi

From: Gregory J. Ward <[email protected]<mailto:[email protected]>>
Sent: Tuesday, January 23, 2018 4:20:26 PM

P.S. Forgot to answer your final question. You can place your receiver surface slightly in front of your window -- you are right that you don't want it in the same plane as another surface with a different material. This would definitely mess things up. You can re-use the same inward-facing surface as used for the view matrix receiver as a sender in the rfluxmtx command, and the material type will be ignored. Having this surface a little inside the window will include the window in the daylight matrix. If you want its influence in the view matrix, you can put your glow/light surface just outside the window, still with its surface normal facing into the room. This would be appropriate if you wanted to use a BTDF for an exterior shading system, for example.
_______________________________________________

7

My apologies, Sandi -- I sent you a link to the wrong year. (Confusingly, they both have 2014 in their titles.)

  https://www.radiance-online.org/community/workshops/2014-london/presentations/day1/Ward_WhatIsNew.pdf

Best,
-Greg

¡¡¡

From: Sandi Sirikhanchai <[email protected]>
Date: January 26, 2018 3:03:44 PM PST

Thanks Greg,

I am going through Sarith’s Tutorial at the moment trying to work out what might be done incorrectly. The link you pasted only has 20 slides and doesn’t have much introduction on rfluxmtx.

Many thanks,
Sandi

From: Greg Ward
Sent: Wednesday, 24 January 2018 6:31 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] Two windows different directions Three Phase simulation

Hi Sandi,

The output of gendaymtx has 146 columns because the first column corresponds to the ground plane, and this is needed for a full calculation. However, you need to create your daylight matrix in the right way to make use of this. I believe this is explained in Sarith's tutorial, and also in my 2013 rfluxmtx introduction, below. Pay special attention to slide 42:

https://www.radiance-online.org/community/workshops/2013-golden-co/Ward-RadianceImprovements.pdf

It can also help to give a -y option in your view matrix calculation, corresponding to the number of sensor points (-y 13). I don't think it's required the way you are doing things, but rmtxop (for example) requires the number of rows and columns to be spelled out in the header. Note that this overrides the actual line breaks in the file, making files like the output of gendaymtx a little more readable. (8760x3 columns are a bit much for some line-based editors.)

Cheers,
-Greg

From: Sandi Sirikhanchai <[email protected]>
Date: January 22, 2018 11:32:50 PM PST

Hi Greg,

I am using 5.2, I will try with “klems_full.cal” and the windows are defined as “glow”.

I will definitely give the multiplication and addition a good go myself first but thank you for letting me know.

Yes, I am going between Sarith’s tutorial and Andy’s gitbook tutorial.

Your explanation to my final questions is incredibly helpful!

In regards to the multiplication of matrices, I am just testing with one window at the moment and I have an error that says “unexpected column count in header”.
The view matrix has 13 rows and 145 columns
The daylight matrix has 145 rows and 2306 columns
The sky matrix has 146 rows and 8760 columns (but there is only 3 columns (RGB) and many many rows)
And the BTDF is in its own different format.

Should the sky matrix say 146? Or 145? My command to create a smx is: “gendaymtx albany.wea > albany.smx”.

Thank you for your help.

Kind regards,
Sandi

8

Hi
@Greg_Ward, I have some follow up questions, which I hope you have time to help with.

For the view matrix calculation:
I have successfully computed multiple view matrices, from a single rfluxmtx command call, using “#@rfluxmtx h=kf u=Z o=output1.mtx”, “#@rfluxmtx h=kf u=Z o=output2.mtx”, … With a glow modifier for each window polygon in the .rad file (unmethours).

  1. During the computation of each v-matrix, what is the definition for the materials of the other windows – is it black i.e. zero reflectance since light sources (glow) are assumed to have zero reflectance ?
  2. What is the difference between using #@rfluxmtx o=output.mtx in the rad file and -o results\photocells_%s.vmx in the function call as described in this post ?

With regards to the daylight matrix calculation:

  1. Is it possible somehow to share the ambient values between each d-matrix calculation to speed up the computation. E.g., for a scene with complex exterior geometry.
  2. What is the most sensible way to define the materials of the other windows, when computing the d-matrices for each window?

Thank you, Tobias

1 Like
9

The other windows can have their full material description, which might be of type “glass” or “aBSDF” or whatever. The calculation of one window’s view matrix includes light reflected off that window, around the room, and back out through other windows, so you should not redefine their materials for a correct calculation.

  1. What is the difference between using #@rfluxmtx o=output.mtx in the rad file and -o results\photocells_%s.vmx in the function call as described in this post ?

You can only have one -o option on the command line, which is equivalent to having an “o=output.mtx” line before the first receiver. Creating separate receiver matrices requires multiple inline “o=” options in front of each receiver surface.

  1. Is it possible somehow to share the ambient values between each d-matrix calculation to speed up the computation. E.g., for a scene with complex exterior geometry.

Of course. Ambient files may always be shared between processes and invocations that have the same lighting conditions.

  1. What is the most sensible way to define the materials of the other windows, when computing the d-matrices for each window?

Again, you don’t have to change the materials to get a correct calculation, and you are better leaving them alone. The only thing you need to do is have separate files for the sender used in each rfluxmtx run, and collect all the receivers into one file. The actual material and surface definitions (and even the #@rfluxmtx comments) do not need to change.

For example, you might compute your multiple view matrices by collecting three window descriptions into one “receivers.rad” file like so:

# All the receivers together for unified rfluxmtx run:
!xform window1.rad window2.rad window3.rad

The file “window2.rad” might contain:

# Our second window:
#@rfluxmtx h=kf o=window2.vmx
void glass glazing2 0 0 3 .9 .9 .9
glazing2 polygon pane2
... (etc.)

Then, you could run:

vwrays -vf view.vf -x 1000 -y 1000 | rfluxmtx -x 1000 -y 1000 [options] - receivers.rad

to compute your view matrices. This would be followed by three separate runs of rfluxmtx for the daylight matrices:

rfluxmtx [options] -af exterior.amb window1.rad skyground.rad > window1.dmx
rfluxmtx [options] -af exterior.amb window2.rad skyground.rad > window2.dmx
rfluxmtx [options] -af exterior.amb window3.rad skyground.rad > window3.dmx

Nothing really needs to change, and the “o=” lines in the sender files are ignored. The above three commands may also be run simultaneously by putting them in the background with ‘&’ or whatever works best on your system.

If you prefer to keep the superfluous “o=” lines out of your window files, you can put them in “receivers.rad” instead:

# Our window collection
#@rfluxmtx o=window1.vmx
!xform window1.rad
#@rfluxmtx o=window2.mtx
!xform window2.rad
#@rfluxmtx o=window3.mtx
!xform window3.rad

You still want to keep your “#@rfluxmtx h=kf” option in each window file, so it chooses the right hemisphere basis. The above avoids the warning otherwise produced by rfluxmtx about the ‘o’ option being ignored in the sender file.

Hope this clarifies things.
-Greg

10

Thank you for your reply - very helpful!

From
Matrix based methods and other examples (e.g. honeybee plus) I was not aware that one can define other modifiers than “glow” to the window polygons in 3PM. All examples I have previously seen of the 3PM uses the “glow” modifier for the window polygons.
Since the goal of the 3PM is to be able to quickly iterate different BSDF files in a matrix multiplication scheme, such as dctimestep, what is then the most suitable modifier definition of the window polygons ? E.g. if the “glass” or a specific/single “BSDF” modifier is used in the calculation of the V and D matrices, then I guess that is incoherent with using several different BSDF/T-matrices in the matrix multiplication scheme.

Maybe I have missed something, but isn’t the content of the ambient files, the irradiance values at discrete points in the scene, used for interpolating the indirect lighting. And rfluxmtx is a wrapper for rcontrib, which deals with contribution coefficients and not actual irradiance values. So how is rfluxmtx able to compute the ambient values when it is computing contribution coefficients ?

Seems ideal to organize the windows in different rad files in this way. A quick question of syntax: What is the difference between placing “#@rfluxmtx h=kf u=Z o=xxx.vmx”, just before the modifier or just before the polygon (as in “matrix based methods”)?

Again, thank you
Best regards
Tobias

11

Hi Tobias,

I’ll just quote you as you have done me:

From “Matrix based methods” and other examples (e.g. honeybee plus) I was not aware that one can define other modifiers than “glow” to the window polygons in 3PM. All examples I have previously seen of the 3PM uses the “glow” modifier for the window polygons.
Since the goal of the 3PM is to be able to quickly iterate different BSDF files in a matrix multiplication scheme, such as dctimestep, what is then the most suitable modifier definition of the window polygons ? E.g. if the “glass” or a specific/single “BSDF” modifier is used in the calculation of the V and D matrices, then I guess that is incoherent with using several different BSDF/T-matrices in the matrix multiplication scheme.

The use of the “glow” type comes from tradition but is not strictly necessary. It is a convenient way to stop tracing rays at their logical end-points. Also, we sometimes use “light” instead of “glow” to attract rays if the windows are very small or distant from the receivers. In any case, you are correct that there is a logical disconnect between selecting a particular material and using different window systems in a 3-phase calculation. However, one could imagine cases where all materials used had an inner glass surface that reflected, say 8%, of rays back to the interior, and you wanted to include that in your calculations. In such a case, you might use an 8% reflectance glass (which could have 0% transmittance) as your proxy for the purpose of view matrix calculations.

The only point I was trying to make is that rfluxmtx was designed to simplify the process and you can use whatever material is most convenient, though there are still trade-offs.

Maybe I have missed something, but isn’t the content of the ambient files, the irradiance values at discrete points in the scene, used for interpolating the indirect lighting. And rfluxmtx is a wrapper for rcontrib, which deals with contribution coefficients and not actual irradiance values. So how is rfluxmtx able to compute the ambient values when it is computing contribution coefficients ?

You are right of course. My mistake. The ambient files in the commands will have no effect, as rcontrib forces -aa 0, turning the indirect cache off. I guess I was confused by your question and didn’t think about it carefully. There is no way to reuse indirect information in the daylight matrix calculation. This is why it is beneficial to run the calculations under Unix, where the -n option works properly for multiprocessing.

Seems ideal to organize the windows in different rad files in this way. A quick question of syntax: What is the difference between placing “#@rfluxmtx h=kf u=Z o=xxx.vmx”, just before the modifier or just before the polygon (as in “matrix based methods”)?

The placement of each #@rfluxmtx directive doesn’t matter, so long as it precedes the actual surface it applies to.

Best,
-Greg

1 Like
12

Hi Greg,
This is very helpful!

To further understand the procedure: When a “glow” type is used, is the rays then stopped/terminated when reaching the window polygon for the first time, and not reflected ?

This seems like the most suitable approach! An inner glass surface with with 0% transmittance and 8% reflectance would then be best modelled by what type? Maybe plastic?

Building on your elaboration and circling back to what was discussed about a single rfluxmtx call to compute multiple v-matrices: Given that any ambient information cannot be shared between multiple rfluxmtx calls for computing d-matrices, does this also imply that each of the V-matrix calculations in a single rfluxmtx call does not share any information between the computations? Other than maybe only computing the octree once?

Many thanks,
Tobias

13

Hi Tobias,

Yes, the glow type stops rays that hit it, and cannot account for interior reflections. The best way to model 8% glass reflectance is with plastic, which also has the Fresnel effects when roughness is zero:

void plastic specular8
0 0
5 0 0 0 0.08 0

More information is shared in a view matrix calculation, as the efficiency of the overall calculation is related to the fraction of rays that hit the intended targets – your windows in most cases. If you have a separate calculation per window, then you wasted a lot of rays hitting the windows you excluded. This is less true if you use “light” as your window modifier, since this targets rays to specific windows, but it still saves time for all the indirect rays.

-Greg