Calculating sDA

[germolinal]

Basically a must for LEED and many others.... unfortunately, this requires using the 3-phase method or the 5-phase method, which is sort of hard to implement here.

Not the first priority, but definitely in consideration.

[agonzalezesteve]

I'm trying to develope the three phase method, taking the OpenStudio measure of Radiance as reference.

The key point will be the algorithm that uses the 3 phase method.

At the moment, I consider that the computation of the daylight matrix is too slow. @germolinal What do you think about using https://nljones.github.io/Accelerad/index.html to accelerate rtrace?

[germolinal]

Lets have this conversation here instead.

The issue with Accelerad (which I understand is pretty awesome) is that it requires NVidia GPUs... that leaves out several computers (all mine, for example). Maybe we can create a forked version that is exactly like Groundhog, but uses accelerad...? Or an option that says "enable accelerad"? How stable is it today?

Regarding the three-phase method, I do not believe it is hard to implement... I have not included it because it is extremely easy to misuse. However, it seems to be the only efficient way of calculating sDA today, as it requires moving shades.

[agonzalezesteve]

I'm confusing issues, I open a new one #40.

[agonzalezesteve]

I have just implemented the three-phase method but I still think that daylight matrix computation is too slow compared to two phase method.

Two phase method

Daylight coefficient matrix

rfluxmtx -v -I+ -ab 6 -ad 1000 -dt 0 -y 250 - ./skies/sky_glow.rad -i ./octrees/scene.oct < ./workplanes/Workplane_Space_101.pts > ./matrices/daylight/Sub_Surface_1.dmx
rfluxmtx: running: rcontrib -fo+ -ab 6 -ad 1000 -dt 0 -I+ -y 250 -faa -c 1 -bn 1 -b "if(-Dx0-Dy0-Dz*1,0,-1)" -m ground_glow -f reinhartb.cal -p MF=1,rNx=0,rNy=0,rNz=-1,Ux=0,Uy=1,Uz=0,RHS=+1 -bn Nrbins -b rbin -m sky_glow "!oconv -f -i ./octrees/scene.oct ./skies/sky_glow.rad"

Three phase method

View matrix

rfluxmtx -v -I+ -ab 6 -ad 1000 -dt 0 -y 250 - ./objects/glow/Sub_Surface_1.rad -i ./octrees/Space_101.oct < ./workplanes/Workplane_Space_101.pts > ./matrices/view/Sub_Surface_1.vmx
rfluxmtx: running: rcontrib -fo+ -ab 6 -ad 1000 -dt 0 -I+ -y 250 -faa -c 1 -f klems_full.cal -p RHS=+1 -bn Nkbins -b kbin(0,1,0,0,0,1) -m window_glow "!oconv -f -i ./octrees/Space_101.oct ./objects/glow/Sub_Surface_1.rad"

Daylight matrix

rfluxmtx -v -ab 6 -ad 1000 -dt 0 ./objects/glow/Sub_Surface_1.rad ./skies/sky_glow.rad -i ./octrees/scene.oct > ./matrices/daylight/Sub_Surface_1.dmx
rfluxmtx: opening pipe to: rcontrib -fo+ -ab 6 -ad 1000 -dt 0 -fda -c 10000 -bn 1 -b "if(-Dx0-Dy0-Dz*1,0,-1)" -m ground_glow -f reinhartb.cal -p MF=1,rNx=0,rNy=0,rNz=-1,Ux=0,Uy=1,Uz=0,RHS=+1 -bn Nrbins -b rbin -m sky_glow -y 145 "!oconv -f -i ./octrees/scene.oct ./skies/sky_glow.rad"
rfluxmtx: sampling 145 directions

I don't know why they have so different computing performance.

[germolinal]

I have just found this out. Sorry for the unreasonably long the delay!

I am not sure why is this happening. I guess it may be occurring because with the 2-phase method you only need to ray-trace once, and for the 3-phase you need to do it twice.