Hi,
I had a look at your model and have a few suggestions:
First up, considering the depth of that space and the fact that except for the one surface everything else is black, the ambient calculations don’t appear to make much sense. Its unlikely that once the light bounces off of the white surface any further changes would occur to the irradiance values.
The material properties themselves do not seem realistic (http://radsite.lbl.gov/radiance/refer/ray.html#Plastic).:
# Material 458c0f14-01bb-11d5-9302-0000863f27ad-000002f6 // Material pré-definido de piso // Diversos
void plastic 458c0f14-01bb-11d5-9302-0000863f27ad-000002f6
0
0
5 0 0 0 0 0.3
# Material END 458c0f14-01bb-11d5-9302-0000863f27ad-000002f6
# Material 665921e0-7a62-442e-9425-e172aa156344-0005cad3 // .Reflective_60 // Generisch
void plastic 665921e0-7a62-442e-9425-e172aa156344-0005cad3
0
0
5 0.6 0.6 0.6 0 1
# Material END 665921e0-7a62-442e-9425-e172aa156344-0005cad3
With regards to comparing rtrace with matrix-based methods, as German pointed out, the sky-matrices for direct sun calculations can only be generated through gendaymtx. So, you’d have to hack a custom wea file with a single time step and pass it on to gendaymtx. The time taken for matrix-based calculations are more because you are simultaneously tracing rays to multiple suns (5165 positions for MF:6). Considering that you are comparing just a single time step, the matrix-based approach seems like an overkill to me.
(The examples given in that tutorial are meant to do “standard” simulations for climate-based daylight modeling. Since you are trying something much more specific, I would suggest referring some of the texts cited in Chapter 2 of that tutorial.)