AW: Re: rtcontrib and rtrace-parameters

Hi Thomas,

many thanks for your comments. They are very helpful and encouraging.

I think you wanted to write 'rtcontrib runs' - at least that's what your
labels say.

Yes, you are absolutely right, sorry.

When you use genskyvec you also remove the sun 'source' from the sky
description and distribute its brightness to the surrounding sky patches.
rtace treats a sky with sun differently than a sky without sun. Therefore
you will not achieve identical results from rtrace and rtcontrib.

OK, I understand.

That obviously depends on your scene complexity. If you have blinds in front
of your window I would say that the results you get are sufficiently
accurate for climate data studies.

If you have a simple geometry like in Axel's tutorial I think that the -as
2048 is overkill. You already have a high -ad setting which should account
for window openings in a typical room.

Effectively you have turned off ambient caching by setting -aa to 0.
rtcontrib does not use ambient caching anyway so that's probably not going
to make a difference. Ambient caching might have smoothed out your
individual point results a bit.

Your -dj value seems high, but given that there are no sources it should not
matter.

That would mean, if I am only interested in daylight (in combination with rtcontrib), I can forget
aa and dj and reduce as.

rtcontrib-runs?

Yes and sorry again.

Perhaps you should investigate where the error originates in your
calculation chain. When you use rtcontrib to calculate illuminance values at
a point the only value affected by the rtrace options is the contribution of
each sky patch. This is only a fraction of the 'brightness' the patch is
ultimately assigned so small variations in the contribution can result in
noticeable changes of the illuminance values. I would start by comparing the
patch contributions between rtcontrib runs. If they are reasonably constant
your error is introduced somewhere else.

That is a good point. I am quite sure, that the differences are coming from the
patch contributions. The calculation time for the rtcontrib run is extremely short,
at least I think so.
What are the critical parameters concerning accuracy for a rtcontrib run, I really
wouldn't have any problems with longer computation time.

IIRC the multiplier for each patch contribution is calculated via genskyvec
at specified directions (saved in tregsamp.dat). That should result in
constant values for the multipliers but you can still check.

OK, they are constatnt over simmilar calls to genskyvec.

Overall I think that your current values are sufficiently accurate. In the
end you will apply these values to a large number of (inaccurate) sky
descriptions to then calculate an average from all these results. The error
you introduce by the use of insufficient sky models should largely exceed
the error resulting from the rtcontrib/genskyvec process.

Thank you for that comment. Yes that is true. But can I say that as long as I compare
different daylighting solutions with the same (inaccurate) processes, I will get still
valid results?

Many thanks and best regards
Martin

···

-----Ursprüngliche Nachricht-----
  Von: Thomas Bleicher <[email protected]>
  Datum: 08.03.2010 10:56:37
  Betreff: Re: [Radiance-general] rtcontrib and rtrace-parameters

Hi Martin.

On Sat, Mar 6, 2010 at 5:37 PM, Martin Klingler <[email protected]>wrote:

The first sky (k4) gives direct sun for the first two measurement points,
with the second sky (k5) there is no sun entering the room.
For the rtcontrib run I use reinhart.cal and compared two MF-settings (2
and 4). The rtrace-options are -ab 6 -ad 4096 -as 2048 -aa 0 -dj 1 -lw
2e-10.
With this settings I get the distributions in Graph1

[graph removed]

To get the distribution I use genskyvec.
Additional I did some rtrace runs with the same options und compared the
results for sky k4 in the second graph

I think you wanted to write 'rtcontrib runs' - at least that's what your
labels say.

When you use genskyvec you also remove the sun 'source' from the sky
description and distribute its brightness to the surrounding sky patches.
rtace treats a sky with sun differently than a sky without sun. Therefore
you will not achieve identical results from rtrace and rtcontrib.

[graph removed]

To this results the are some questions:
1.) Are this useful rtrace-options, am I on the right track?

That obviously depends on your scene complexity. If you have blinds in front
of your window I would say that the results you get are sufficiently
accurate for climate data studies.

If you have a simple geometry like in Axel's tutorial I think that the -as
2048 is overkill. You already have a high -ad setting which should account
for window openings in a typical room.

Effectively you have turned off ambient caching by setting -aa to 0.
rtcontrib does not use ambient caching anyway so that's probably not going
to make a difference. Ambient caching might have smoothed out your
individual point results a bit.

Your -dj value seems high, but given that there are no sources it should not
matter.

2.) What can I do, to get closer to the rtrace-results?

As I said above, you can not reproduce the direct calculation with
genskyvec. You could split out the direct component and do a separate
calculation just for the sun. It will just make things far more complicated,
though.

You could try and switch off Monte Carlo sampling with '-u-'. That should
give you a deterministic sampling pattern which should result in 'identical'
values.

3.) MF=2 seems to get smoother results, than MF=4 - dose that make
sense?

4.) Can I reduce the differences between different rtrace-runs with the

identical options?

rtcontrib-runs?

Perhaps you should investigate where the error originates in your
calculation chain. When you use rtcontrib to calculate illuminance values at
a point the only value affected by the rtrace options is the contribution of
each sky patch. This is only a fraction of the 'brightness' the patch is
ultimately assigned so small variations in the contribution can result in
noticeable changes of the illuminance values. I would start by comparing the
patch contributions between rtcontrib runs. If they are reasonably constant
your error is introduced somewhere else.

IIRC the multiplier for each patch contribution is calculated via genskyvec
at specified directions (saved in tregsamp.dat). That should result in
constant values for the multipliers but you can still check.

Overall I think that your current values are sufficiently accurate. In the
end you will apply these values to a large number of (inaccurate) sky
descriptions to then calculate an average from all these results. The error
you introduce by the use of insufficient sky models should largely exceed
the error resulting from the rtcontrib/genskyvec process.

Anyway, good that there is more interest in validating climate data
calculations.

Regards,
Thomas