Validate sunlight hours results against ladybug's vector based component

[mostaphaRoudsari]

I started the process with testing an interior space with a blocking box. points the are close to the edge conditions are where the errors happens in Radiance

Currently, I'm using -u and less than 3% of points doesn't match the values from ladybug. This number can be increased by introducing more edge conditions.

I tried turning off -u switch and set -aa to 0 and played with other parameters but couldn't get more accurate results. @sariths do you have any input on radiance options for this case? I remember you told me that -lw was the other value that can change the results but it wasn't as effective in this case. Here is the command line.

c:\radiance\bin\rcontrib -M c:\ladybug\untitled\sunlighthour\untitled.sun -I -ab 0 -ad 10000 -dc 1.0 -u c:\ladybug\untitled\sunlighthour\untitled.oct < c:\ladybug\untitled\sunlighthour\untitled.pts > untitled.dc

Grasshopper file is under test folder.

[sariths]

Hi @mostaphaRoudsari, how low did you keep the lw values? I remember using -lw at around 0.001 or lower. Are we confident that the truth simulation (ladybug) in this case is accurate ? I couldn't affect any changes to the simulation by changing the ad value here:

Anyway, this question is a good excuse for me to do some deeper research into rendering parameters. I will keep you posted if I find something useful.

[mostaphaRoudsari]

Hi @sariths! Unless you turn off u switch I don't think changing ad is going to make a difference. I did try as less as 0.0001 and also tried to set the parameters based on 5-Phase tutorial. If you run the analysis a couple of times there is a chance to get the results with no errors but I think since this is just the direct view we should be able to get an always accurate results. I might be wrong though.

I checked the results for ladybug by running intersections and find intersection points, and they are always correct as there is no randomness in the process.

BTW do you think that I should open up other Radiance parameters for sunlighthours? I was under the impression that -ad is the only one that will be useful but seems that I was wrong. I can overwrite -ab and -dc and give a warning if user input wrong values. Let's see if you can find the magic combination.

[sariths]

There is some dark magic inside Radiance that I am always learning more about. I vividly remember this thread because of the image which Alstan had posted : Missing solar source visibility from gendaylit for multiple ambient-bounces. Unfortunately, his images aren't there anymore (thanks Dropbox :\ ). The discussion there is actually starts with bounces, divisions etc. but ends with pixel-sampling rate. I wonder if the solution to this our issue lies in the analogus -dt -dc or -ds for rtrace.

Are we always below the solution for Ladybug ? If so, that would imply that we aren't sending out enough rays or aren't hitting the sources with enough accuracy.

Anyways, I am going to do some reading on this one and learn more to have better guesstimate.

[sariths]

@mostaphaRoudsari I just read through a bunch of references on direct calculations. To me it appears that you are doing everything right. The primary settings for direct as per RwR and the supporting papers suggest dc and dt for improving/decreasing accuracy. Those two values are already set to the best levels.

I noticed that in the bat file on my system only dc is assigned. c:\radiance\bin\rcontrib -ad 10000 -dc 1 -ab 0 -I -u -M c:\ladybug\untitled\sunlighthour\untitled.sun c:\ladybug\untitled\sunlighthour\untitled.oct < c:\ladybug\untitled\sunlighthour\untitled.pts >untitled.dc Are you changing both dc = 1 and dt ? The other thing that noticed is that the error doesn't change if we removed the block from the view.

[mostaphaRoudsari]

@sariths thanks for checking! I don't set dt currently in the recipe but I added it manually for testing. the same goes to lw. I will modify the recipe tomorrow. If that is the case then maybe we should also remove the ad input from the component and set it to a high default value.

The other thing that noticed is that the error doesn't change if we removed the block from the view.

As far as I have seen the error always stays for around %3 of the points with or without the context geometry. Maybe we should post this to unmethours as I'm sure Andy and Greg will have some inputs on this based on their experience while developing 5 phase method (and their experience in general!)

[sariths]

@mostaphaRoudsari I think asking them is a good idea. I am still reading on the subject. If I get anything more on this I will update it here.

[mostaphaRoudsari]

See these three discussions:

Radiance options for direct sunlight calculation rcontrib error: internal - too many modifiers rcontrib misses one of the modifiers if number of modifiers between 240-420

[jurrijn]

I would like to make a direct sunlight hours calculation based on radiance. I was wondering if there is a working gh. sample file available. Thanks in advance.

[mostaphaRoudsari]

Try this file.. You need to install Honeybee[+] to be able to try this file.