<html>
<head>
<title></title>
<meta name="GENERATOR" content="Consolidate">
</head>
<BODY BGCOLOR="#FFFFFF"><font FACE="Arial" SIZE="2" ><font COLOR="#000000">Hi Thomas,<br> <br> many thanks for your comments. They are very helpful and encouraging.<br> <br> <font COLOR="#000000" >> I think you wanted to write 'rtcontrib runs' - at least that's what your<br> > labels say.<br> <font COLOR="#000000">Yes, you are absolutely right, sorry.<br> <br> <font COLOR="#000000" >> When you use genskyvec you also remove the sun 'source' from the sky<br> > description and distribute its brightness to the surrounding sky patches.<br> > rtace treats a sky with sun differently than a sky without sun. Therefore<br> > you will not achieve identical results from rtrace and rtcontrib.<br> <font COLOR="#000000">OK, I understand.<br> <br> <font COLOR="#000000" >> That obviously depends on your scene complexity. If you have blinds in front<br> > of your window I would say that the results you get are sufficiently<br> > accurate for climate data studies.<br> ><br> > If you have a simple geometry like in Axel's tutorial I think that the -as<br> > 2048 is overkill. You already have a high -ad setting which should account<br> > for window openings in a typical room.<br> ><br> > Effectively you have turned off ambient caching by setting -aa to 0.<br> > rtcontrib does not use ambient caching anyway so that's probably not going<br> > to make a difference. Ambient caching might have smoothed out your<br> > individual point results a bit.<br> > <br> > Your -dj value seems high, but given that there are no sources it should not<br> > matter.<br> <font COLOR="#000000">That would mean, if I am only interested in daylight (in combination with rtcontrib), I can forget<br> aa and dj and reduce as.<br> <br> <font COLOR="#000000" >> rtcontrib-runs?<br> Yes and sorry again.<br> <br> > Perhaps you should investigate where the error originates in your<br> > calculation chain. When you use rtcontrib to calculate illuminance values at<br> > a point the only value affected by the rtrace options is the contribution of<br> > each sky patch. This is only a fraction of the 'brightness' the patch is<br> > ultimately assigned so small variations in the contribution can result in<br> > noticeable changes of the illuminance values. I would start by comparing the<br> > patch contributions between rtcontrib runs. If they are reasonably constant<br> > your error is introduced somewhere else.<br> That is a good point. I am quite sure, that the differences are coming from the<br> patch contributions. The calculation time for the rtcontrib run is extremely short,<br> at least I think so.<br> What are the critical parameters concerning accuracy for a rtcontrib run, I really<br> wouldn't have any problems with longer computation time.<br> <br> <br> > IIRC the multiplier for each patch contribution is calculated via genskyvec<br> > at specified directions (saved in tregsamp.dat). That should result in<br> > constant values for the multipliers but you can still check.<br> <font COLOR="#000000">OK, they are constatnt over simmilar calls to genskyvec.<br> <br> <font COLOR="#000000" >> Overall I think that your current values are sufficiently accurate. In the<br> > end you will apply these values to a large number of (inaccurate) sky<br> > descriptions to then calculate an average from all these results. The error<br> > you introduce by the use of insufficient sky models should largely exceed<br> > the error resulting from the rtcontrib/genskyvec process.<br> <font COLOR="#000000">Thank you for that comment. Yes that is true. But can I say that as long as I compare<br> different daylighting solutions with the same (inaccurate) processes, I will get still<br> valid results?<br> <br> Many thanks and best regards<br> Martin<br> <br> <b> -----Ursprüngliche Nachricht-----<br> Von: </b>Thomas Bleicher <<font COLOR="#0000ff"><u><a href='mailto:radiance-general@radiance-online.org'>radiance-general@radiance-online.org</a></u><font COLOR="#000000">><br> <b> Datum: </b>08.03.2010 10:56:37<br> <b> Betreff: </b>Re: [Radiance-general] rtcontrib and rtrace-parameters<br> <font COLOR="#000000" ><br> <br> Hi Martin.<br> <br> On Sat, Mar 6, 2010 at 5:37 PM, Martin Klingler<br> <<font COLOR="#0000ff"><u><a href='mailto:martin@lichttechnik.co.at'>martin@lichttechnik.co.at</a></u><font COLOR="#000000" >>wrote:<br> <br> > The first sky (k4) gives direct sun for the first two measurement points,<br> > with the second sky (k5) there is no sun entering the room.<br> > For the rtcontrib run I use reinhart.cal and compared two MF-settings (2<br> > and 4). The rtrace-options are -ab 6 -ad 4096 -as 2048 -aa 0 -dj 1 -lw<br> > 2e-10.<br> > With this settings I get the distributions in Graph1<br> ><br> <br> [graph removed]<br> <br> <br> > To get the distribution I use genskyvec.<br> > Additional I did some rtrace runs with the same options und compared the<br> > results for sky k4 in the second graph<br> ><br> <br> I think you wanted to write 'rtcontrib runs' - at least that's what your<br> labels say.<br> <br> When you use genskyvec you also remove the sun 'source' from the sky<br> description and distribute its brightness to the surrounding sky patches.<br> rtace treats a sky with sun differently than a sky without sun. Therefore<br> you will not achieve identical results from rtrace and rtcontrib.<br> <br> [graph removed]<br> <br> <br> > To this results the are some questions:<br> > 1.) Are this useful rtrace-options, am I on the right track?<br> ><br> <br> That obviously depends on your scene complexity. If you have blinds in front<br> of your window I would say that the results you get are sufficiently<br> accurate for climate data studies.<br> <br> If you have a simple geometry like in Axel's tutorial I think that the -as<br> 2048 is overkill. You already have a high -ad setting which should account<br> for window openings in a typical room.<br> <br> Effectively you have turned off ambient caching by setting -aa to 0.<br> rtcontrib does not use ambient caching anyway so that's probably not going<br> to make a difference. Ambient caching might have smoothed out your<br> individual point results a bit.<br> <br> Your -dj value seems high, but given that there are no sources it should not<br> matter.<br> <br> <br> > 2.) What can I do, to get closer to the rtrace-results?<br> ><br> <br> As I said above, you can not reproduce the direct calculation with<br> genskyvec. You could split out the direct component and do a separate<br> calculation just for the sun. It will just make things far more complicated,<br> though.<br> <br> You could try and switch off Monte Carlo sampling with '-u-'. That should<br> give you a deterministic sampling pattern which should result in 'identical'<br> values.<br> <br> <br> > 3.) MF=2 seems to get smoother results, than MF=4 - dose that make<br> > sense?<br> ><br> 4.) Can I reduce the differences between different rtrace-runs with the<br> > identical options?<br> ><br> <br> rtcontrib-runs?<br> <br> Perhaps you should investigate where the error originates in your<br> calculation chain. When you use rtcontrib to calculate illuminance values at<br> a point the only value affected by the rtrace options is the contribution of<br> each sky patch. This is only a fraction of the 'brightness' the patch is<br> ultimately assigned so small variations in the contribution can result in<br> noticeable changes of the illuminance values. I would start by comparing the<br> patch contributions between rtcontrib runs. If they are reasonably constant<br> your error is introduced somewhere else.<br> <br> IIRC the multiplier for each patch contribution is calculated via genskyvec<br> at specified directions (saved in tregsamp.dat). That should result in<br> constant values for the multipliers but you can still check.<br> <br> <br> Overall I think that your current values are sufficiently accurate. In the<br> end you will apply these values to a large number of (inaccurate) sky<br> descriptions to then calculate an average from all these results. The error<br> you introduce by the use of insufficient sky models should largely exceed<br> the error resulting from the rtcontrib/genskyvec process.<br> <br> Anyway, good that there is more interest in validating climate data<br> calculations.<br> <br> Regards,<br> Thomas<br>
<br>
</font>
</body>
</html>