MF4 error - unexpected row count in header

Hello all -
I’m trying to work through some 3phase (likely going to 5phase) methods with the new tutorials (haven’t done it since Andy’s original tutorial).
Everything seems to be working out as expected when I work through with normal Klems patches. I had some oddities in my data (200k lux vertical illum for some summer hours) so thought I’d try to run at MF4 to see if the larger sky patches were the culprit.
I was able to run all the individual matrices, but the combination at the dctimestep command gives me an error of “fatal - unexpected row count in header”.

Using getinfo on my MF4 matrices, I get:
vmtx

rcontrib -fo+ -ab 12 -ad 50000 -lw 2e-6 -w -n 96 -I+ -faa -c 1 -f reinhartb.cal -p MF=4,rNx=0.8232,rNy=0.567752,rNz=0,Ux=0,Uy=0,Uz=1,RHS=+1 -bn Nrbins -b rbin -m A_GLAZ
NCOMP=3
NCOLS=2305

dmtx

rcontrib -fo+ -ab 2 -ad 1000 -lw 1e-4 -w -n 96 -fdf -c 1000 -f reinhartb.cal -p MF=4,rNx=0,rNy=0,rNz=-1,Ux=0,Uy=1,Uz=0,RHS=+1 -bn Nrbins -b rbin -m skyglow -bn 1 -b if(-Dx0-Dy0-Dz*1,0,-1) -m groundglow -y 2305
NCOMP=3
NROWS=2305
NCOLS=2306
BigEndian=0
FORMAT=float

skymtx

gendaymtx -m 4 wea/LAX.wea
LATLONG= 33.93000000 -118.40000000
NROWS=2306
NCOLS=8760
NCOMP=3

bsdf - have tried a few different ones but all get same error

My geometry for vmtx & dmtx (same geometry) has the following line to direct rfluxmtx -

#@rfluxmtx h=r4 u=Z

Not really sure what’s happening, any help is much appreciated (I’m sure it’s something simple / user input error). I’m going to try to see if 5phase on the ‘working’ klems simulation solves my issues in the meantime.

Just for clarity / my own peace of mind, the view matrix -p MF… bit is for the geometry, but that line in the daylight matrix represents the orientation of the sky right? The window geometry is the same, so just want to make sure that the correct orientation is known. I’m guessing yes, but all the rfluxmtx ‘shortcuts’ compared to Andy’s original makes me curious to know it all falls in line. Again I’m sure it does, just want to make sure. Some simple tests of a box with a skylight all seems to translate correctly, but checking for my own sanity as I try to troubleshoot all this stuff.

Thanks in advance, hope all is well with everyone out there!
Chris

This might be the culprit. The hemispherical sampling for the view matrix should be a Klems basis (h=kf, h=kq etc). Assuming that you are working with a standard full Klems-basis BSDF file, it should be h=kf. Right now, matrix multiplication is failing because there is a mismatch in the rows and columns.
With regards to files, the only changes required to make the MF:4 simulation run are to change the sky file (as shown here). You also need to specify -m 4 ,instead of -m 1 , in the gendaymtx command (I see that you are already doing that).

As a test, I made some minor tweaks to the Three-Phase example from the new Radiance tutorial to get the MF:4 simulation to run. You can find the files here. The commands are in 3PM.sh.

Regards,
Sarith

1 Like

Thank you so much Sarith. I saw in Andy’s tutorial that he had MF4 daylight matrix and weather (I thought) so tried that. This worked, thank you!
So this is subdividing the sky into a finer patching, but those still get passed to the standard klems 145 patches at the window? The hope is a better assignment of solar position, limiting it to 1 klems patch vs maybe 3 patches (as your sky matrix images show in the the tutorial). We still have that 1 larger patch distributing light into our scene, but the hope (for vertical glass) is that the smaller patches near the zenith of the klems dome are good enough for many simulations. If more resolution is needed, we can jump to 5 phase.
When would we use the h=n4 that gets passed to rfluxmtx?
Guess this is the confusing part about the simplified (which I like) 3+ phase methods. Your tutorial is very helpful, but once we need to adjust the basic settings or non-vertical apertures we’re a little in the dark. Andy’s original tutorial shows how to handle these, but the process is a bit different now. He was very helpful here when i was struggling with non-standard things in the past, so was able to try to hack it together (I hope).
Thanks again, now to see if this solved my other errors.

Hi Chris,

As per your current setup, yes, the rays are still passed to the 145 patches at the window. 5-Phase would be the way to go for more precise results. If you are not actually working with a complex fenestration, and are just using simple glazing instead, it would be a lot simpler to work with daylight coefficients with direct-sun correction.
image

I have called this the DDS method in the tutorial, but there is no interpolation between sun positions as proposed in the 2007 paper. However, as the tutorial example uses 5165 suns instead of 2305, I think the error is likely not much. Andy had discussed this in the context of the 5-Phase method in his tutorial (page 8).

I am not sure I understand as I am not aware of an nN option for rfluxmtx. If you are referring to the sky subdivision scheme (rN), and are not interested in doing the sun correction as suggested in the “DDS” example, you will probably get more accurate results with 2305(h=r4) or 5165(h=r6) patches than you will with 145 patches. But working with that many more sky patches will also necessitate much more intensive ambient parameters ( higher -ad , -lw), leading to higher simulation runtimes.

Is there a specific example that you could share? I think one of us here might be able to suggest a workflow with rfluxmtx. Taoning had presented a couple of new workflows and tips in the recent Radiance workshops that you might find helpful (2018, 2019)

Regards,
Sarith