Differences in three phase method results between rcontrib and rfluxmtx methods


#1

Dear all,

I am trying to transition some Matlab scripts for performing daylight simulation using the three phase method which are based on the deprecated tutorial by Andy McNeil (using calls directly to rcontrib) to the new method, as explained in Sarith Subramaniam’s tutorial (using the rfluxmtx command). In doing so I found contrasting results in my implementation of these two methods.

To check whether I am using them correctly I redid example 1 from the Andy McNeil tutorial with both methods. Unfortunately I cannot reproduce the results as in the example with rfluxmtx using (largely) the same settings.

Example one of the tutorial gives the illuminance on 6 sensor points (the first being outside), for three BSDF alternatives with a CIE clear sunny at 21st of December 15:00.

Deeper into the space I am getting much lower illuminance levels when using rfluxmtx, dropping even far below 500 lux where the rcontrib method predicts illuminance above 500 lux (see the images below). I also ran a regular simulation with rtrace (with BSDF material and high settings) for the no-blinds case.



Does anyone have a suggestion of what I might be doing wrong, or whether these differences are to be expected? I noticed in the verbose reporting of rfluxmtx that it calls reinhartb.cal rather than reinhart.cal and that the –b and –bn arguments of rcontrib are assigned in a different manner.

My matlab scripts will not be very legible so I have put the commands that are sent to Radiance in two text files (dropboxLinks: one for rcontrib and one for rfluxmtx) together with the contents of the files describing the scene. Below I have summarized the most important commands (materials are contained within the room and window definitions):

Kind regards,

Samuel

3 Phase commands rcontrib:

_oconv …\Radiance\objects\room.rad …\Radiance\objects\windows.rad …\Radiance\objects\ground.rad > …\Radiance\LoE_vmx.oct
(In the Subramariam tutorial the ground is contained within the octree also for the VMX so to be consistent I did the same here).

rcontrib -f klems_full.cal -b kbinS -bn Nkbins -m windowglow -I+ -ab 12 -ad 50000 -lw 2e-5 …\Radiance\LoE_vmx.oct < …/Radiance/data/photocells.pts > …/Radiance/matrices/vmx/photocellsOneWindow.vmx_

oconv …\Radiance\objects\room.rad …\Radiance\objects\ground.rad …\Radiance\skies\sky_white1.rad > …\Radiance\LoE_dmx.oct_

genklemsamp -vd 0 -1 0 …\Radiance\objects\windows.rad | rcontrib -c 1000 -e MF:4 -f reinhart.cal -b rbin -bn Nrbins -m sky_glow -faf …\Radiance\LoE_dmx.oct > …/Radiance/matrices/dmx/southWindow_one.dmx_

dctimestep -h …/Radiance/matrices/vmx/photocellsOneWindow.vmx …/Radiance/data/McNEILtut_singleClr.xml …/Radiance/matrices/dmx/southWindow_one.dmx …/Radiance/skiesVect/12_21_15.skv | rcalc -e “$1=179*($10.265+$20.670+$3*0.065)” > …/Radiance/results/illum_122115_clear.dat_

3 Phase commands rfluxmtx: _

oconv -f…/Radiance/objects/room.rad …/Radiance/objects/ground.rad > …/Radiance/octrees/model_rflx.oct_

window_200.rad:
void glow generic_glass_Full
0
0
4 1.000 1.000 1.000 0

#@rfluxmtx h=kf u=Z
generic_glass_Full polygon WindowFull
0
0
12 0.5 -.15 1
0.5 -.15 2
3.5 -.15 2
3.5 -.15 1

rfluxmtx -v -I+ -ab 12 -ad 50000 -lw 0.00002 -y 6 - …/Radiance/varShading/window_200.rad -i …/Radiance/octrees/model_rflx.oct < …/Radiance/data/photocells.pts > …/Radiance/matrices/vmx/photocellsWindow_200.vmx_

sky_white1.rad:
#@rfluxmtx u=+Y h=u
void glow groundglow
0
0
4 1 1 1 0

groundglow source ground
0
0
4 0 0 -1 180

#@rfluxmtx u=+Y h=r4
void glow skyglow
0
0
4 1 1 1 0

skyglow source skydome
0
0
4 0 0 1 180

rfluxmtx -v -ff -ab 4 -ad 1000 -lw 0.001 -c 1000 …/Radiance/varShading/window_200.rad …/Radiance/skies/sky_white1.rad -i …/Radiance/octrees/model_rflx.oct > …/Radiance/matrices/dmx/southWindow_200.dmx_
(I also tried using the rcontrib defaults as in the other method but this did not change much)

dctimestep …/Radiance/matrices/vmx/photocellsWindow_200.vmx …/Radiance/data/McNEILtut_singleClr.xml …/Radiance/matrices/dmx/southWindow_200.dmx …/Radiance/skiesVect/12_21_15.skv | rmtxop -fa -c 47.435 119.93 11.635 -> …/Radiance/results/illum_122115_clear.dat_


#2

It looks as though your window’s surface normal is pointed towards the exterior. It needs to point towards the interior for rfluxmtx. [WRONG – see below!] (Unfortunately, genklemsamp expects the opposite.)
I am also not happy with the practice of setting -lw to exactly 1/ad, as you are much better off setting it smaller – maybe a tenth of 1/ad.
The only other concern is that you used -ab 4 in your rfluxmtx command for the exterior, whereas the default for rcontrib is -ab 1. I guess that’s what your note about trying the rcontrib defaults was about.


#3

Hi Greg,

Thank you for your reply. I copied the window coordinates from the tutorial, the other geometry comes from Axel Jacob’s rcontrib tutorial. If I follow the right-hand-rule I would say my normals are facing inward. I also opened the geometry using Honeybee, there it comes out the same (see image below).

If I look at the verbose reporting of rfluxmtx for the viewmatrix it says -b kbin(0,1,0, 0,0,1) which I think corresponds with the ‘kbinS’ that I assign when generating the viewmatrix within my rcontrib method.

When generating the daylight matrix using genklemsamp: I assign ‘-vd 0 -1 0’. This is correct for a window normal facing inward in the +y direction right?

I will also try the lower -lw settings.

Kind regards,

Samuel


#4

Sorry, my mistake. I had the coordinates the wrong way around in my head… Your use of genklemsamp directions and ‘kbinS’ seem proper as well.

Upon further examination, I’m thinking the biggest source of error may be the -c 1000 sampling of a MF:4 Reinhart sky, which has over 2300 patches. You aren’t going to get an accurate daylight matrix with just 1000 samples, and your rfluxmtx and genklemsamp commands will create different sampling patterns due to randomness, so they won’t get the same answer. I would recommend increasing -c to 10000 or so to see if that doesn’t resolve the discrepancies.

The first point in the photocells file doesn’t seem to align with the others – don’t know if this was intentional. Also, you didn’t give your ground.rad file, so I couldn’t reproduce your results.


#5

Hi Greg,

I tried increasing sampling in genklemsamp. However I am running on a Windows machine without means to parallel process a single command. 10000 samples and a MF:4 sky takes very long; so I decreased the sky discretization to MF:1 as an alternative whilst keeping the –c 1000 sampling. The large differences between rcontrib and rfluxmtx remain (also tried MF:1 and -c 5000, which does not change the conclusions).

I doubt whether the problem lies within the daylight matrix side though. I tested crossing the viewmatrix produced with rcontrib with the daylightmatrix made with rfluxmtx, and vice versa (see image below which are based on MF:1 with -c 1000). This suggest that the difference lies within the view matrix (using rcontrib for the view matrix consistently gives higher illuminance deeper into the space).

I also tried lowering the –lw further. This does not solve the differences but increases runtime significantly for making the daylight matrix.

Am I correct that, if genklemsamp sampling or –lw and –ad settings would be the cause of these differences, than I would also have to see quit large differences between subsequent runs using the same settings and method? When I repeat the same batch file I get variations of 10-30 lux at the last sensor point. These variations are however very small compared to the 500 lux of difference I get between rfluxmtx and rcontrib.

I am aware that the first sensor point is on the outside. This case and the render settings come from the tutorial (I think it was included there for didactical purposes).

My apologies for not including the full definition earlier. I now uploaded a zip on dropbox (hyperlink). It contains four folders (one for each of the variations in the graph above). I put all the commands in a batch files which I believe should also run with Unix (my apologies if they do not).

Thank you for your help with this.

Kind regards,

Samuel


#6

I just noticed that you are working from the 5.0 official release, which is by now two releases behind!
You should definitely get the same view matrix for these two runs, as you are basically running the same rcontrib command, and rfluxmtx is just acting as a pass-through. I don’t know why your results are in error, but I get the right answer using the new official 5.2 release. I suggest you download the latest installer from NREL and try again with the newer version.


#7

Hi Greg,

I found what was wrong, and it’s rather silly; In the oconv command I was using for fluxmtx there was a space missing between -f and objects/room.rad. As a results the octree used by rfluxmtx containted only a window and the ground. I remember checking the octree with RVU but I must have been looking at the wrong .oct file.

Sorry for this silly mistake and thanks for all the help. Positive outcomes of this are that now at least I have updated my Radiance (something that I indeed should have done already long ago) and I understand a bit better now how rfluxmtx does it’s work.

Kind regards,

Samuel


#8

Oh, I’m glad you found it! I’m not sure I ever would have. I was entering the oconv command myself, so I didn’t even look at your octree headers, and only the working .bat file.