For some evaluation purpose I set up a series of tests using ‘conventional’ rtrace. Then I started comparing them to results obtained with the two phase method but experienced some difficulties. All simulations are run on windows 10, using radiance 5.2. The test case used is a rather simple geometry with a black box, having an opening on one side. Light is scattered inside by a diffusely reflecting plane at some distance from the opening (0.65 m and 1 m … 8 m from receiving plane). No sky is considered, only sun light with an incidence angle of 60° on the scattering plane (latitude 30°, longitude 0°, 21th march, +12:00).
So far I tested rtrace simulations with different parameters and wanted to compare the results to the matrix based methods but I am having trouble with this. Using the simple two phase method simulation times are very long whilst the results still are quite poor. Thus I tried using the improved sun calculation with genskyvec / rcontrib, as proposed in the Radiance Matrix Based Methods manual. With the result that the calculation time are even longer and there resulting irradiance is about a factor of 15 lower than the one obtained with rfluxmtx.
Rfluxmtx was run with these parameters (calculation time ~7300 s):
rfluxmtx -ad 30000 -ab 4 -lw 1.0e-4 -I+ (-m 2 sky generation)
What is driving up calculation time is the ad parameter but even more the lw parameter. Effectively sensor points on the scattering plane get calculated fast, what takes so long to calculate are the points inside the box.
And rtrace e.g. with these (calculation time ~2 s):
rtrace -aa 0.15 -ab 4 -ad 256 -ar 32 -as 20 -dc 0 -dj 0.7 -dp 32 -dr 0 -ds 0 -lw 0.05 -st 1.0 -I
So my question, what might cause the scaling in genskyvec / rcontrib, which parameters for rfluxmtx are supposed to give reliable results, is there a way to reduce calculation times and what would be an alternative approach using rtrace and weather files?
Of course I can supply more information and files from the simulations if necessary, just let me know.
Cheers
Christian
I do not have a full answer for you, but I can tell you some things from my
experience… I have been doing similar things recently as part of the test
cases for Emp.
If you are working only with the sun, you should not expect the
2-phase method to work very well. The sun in the two-phase method is spread
into 3 or 4 (I think 4) sky patches, which makes it very big compared to
the gendaylit sun which is 0.533 degrees wide. Also, the gendaylit sun is
made of light material, while the 2-phase method sky is made of Glow. This
is important because Radiance treat these materials differently
Even if you use sharp suns for the matrix-based method (i.e.
gendaymtx -d -5 0.533 | dctimestep ), you cannot expect the results to be
exact at every point at every timestep. This is caused by the sun being in
(slightly) different positions in the matrix-based (which predefines sun
locations) and the continuous gendaylit’s positions. This will only be
noticeable at the edges of shadows, though… for example, the exact moment
in which a sensor becomes exposed to the direct sun will be slightly
shifted from reality.
Hi!
Thanks a lot for your reply and please excuse the delay in getting back to this.
As I still could not solve the problem, I have made a short perl script calculating the results for the above described test in three ways. The script including the geometry, materials and sensor points used are within this zip file:
At first using RTrace, then using RFluxmtx (in this case I have to modify the skyfile generated by gensky in order to get a sun only illumination) and third using the improved method for sun calculation, as described in the radiance matrix based methods manual with RCalc / RContrib.
The results are written to the three files PlaneSurfaces_Refl_1_revout_radout.rad, PlaneSurfaces_Refl_1_revout_radout2.rad and PlaneSurfaces_Refl_1_revout_radout3.rad. The radiance is calculated for 200 points in front of the reflector, 4 points aligned with the four edges of the reflector, but inside the box and one point on top of the box (points are in this order).
Rfluxmtx results are still somewhat comparable to RTrace, though the variance is high, especially for the four points within the box and thus calculated accuracy would be poor.
RContrib results are completely off compared to the other two ones. Whilst Rtrace / Rfluxmtx give values in turn of 120 for the incident vertical radiation on the plane, RContrib gives something about 0.9.
Any help is appreciated!
I am not entirely sure what your script does in detail (it is well
documented, but I am not even amateur in Perl). That being said, some
comments:
I believe cat $name$next.sky | genskyvec -m $mdiv > $name$next.vec
does not generate a sky without the diffuse component (I think it
internally adds the ground and sky sources). However, I would say that you
can specify a -c 0 0 0 (sky colour of Zero) and get a Sun only result.
Since that will still give a ground component, I guess you can eliminate
the ground from the skymat file (you will get a zero contribution of that
patch).
For the reasons explained in point 1 and some more, I usually end up
programmatically writing a “.WEA” file with only one line of measured data
and calling GENDAYMTX. That program provides much more options! including
the -5 one, as well as considering or not the diffuse or direct components.
Then, I believe your RFLUXMTX command requires a -I+ option to
calculate illuminance, which is what you are calculating on the RTRACE
version
Finally, the command cat $name$next.sky | genskyvec -m $mdiv >
$name$next"2".vec does not do what you want for the “improved sun
calculation”. For such method, you require a completely different GENSKYVEC
calculation, that you will find in GENDAYMTX. Again, read Point 2. The
options you need for GENDAYMTX, in this case, are “-d” (eliminates the sky)
and “-5 0.533” (asks for a single sharp sun sky vector). I think the order
of these options is important… not sure which one goes first.
Hi!
Thanks for your reply, I feel I am getting closer to a result. Well I am not a perl programmer either, this (one of) my first perl script(s), completely experimental programming.
->1 The output of $name$next.sky | genskyvec -m $mdiv > $name$next.vec, which is PlaneSurfaces_Refl_12.vec looks quite sun only (a lot of lines with zero and some bright spots). Maybe someone can comment on this?
->3: You are absolutely right about the missing -I+. It got lost, “translating” the problem from M$ to Linux. Actually I am running / testing these things with M$, I just made this script, as I felt, it might make it easier getting help here. I updated the shell script with the missing -I+, in case someone else wants to have a look at these issues. With the updated -I+ the -lw parameter shows more effect in Linux and the results look quite comparable to rtrace at a first test, I will try to test more cases, soon. Leaving this point with the problem, that under windows it is unusable due to exhaustive calculation times for meaningful -lw parameter values (under windows I stopped with -lw 1e-4 / 8000 s and poor results).
->2, 4: I adapted the rcalc / rcontib from the manual ( https://www.radiance-online.org/learning/tutorials/matrix-based-methods Appendix B, page 95), also in this case, maybe someone can comment on these lines? Anyway, I will try using gendaymtx, as you suggested and give a feedback, but this might take some time.
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.)
Hi!
Thanks for the reply and sorry for the very long delay, to pick up working on this. Was caught preparing lectures.
Well you said, I’d have to hack a custom weather file. Can you give some more details on that? I tried to mount some test scheme to check genskyvec output against gendaymtx output. As I want to use a generated sky, I tried to generate a custom weather file in this way:
generate a sky file gensky 3 21 +12 +s -a 0 -o 30
generate oct(ree) with sun only and run rtrace to determine direct horizontal irradiance DHI: echo 0 0 0 0 0 1 | rtrace -w -h -I -ad 4096 -ab 1 > DHI
generate sky file without sun gensky 3 21 +12 -s -a 0 -0 30
generate oct(ree) with skydome and sky and run rtrace as above to determine global diffuse irradiation GDI
generate a wea(ther) file with: place undefined latitude 0.0000 longitude -30.0000 time_zone 0 site_elevation 0.00 weather_data_file_units 1 3 21 12.00 DHI GDI
with DHI and GDI as determined from above
pass this to gendaymtx
compare output to output from genskyvec
Another question is, if I want to use data from a weather file to generate a sky with gensky, using DHI and GDI in this way: gensky 3 21 +12 -s -a 0 -0 30 -B GDI -R DHI
would be correct?
Thanks a lot
Chris
