Radiance parameters for annual daylight recipe in Honeybee[+]

Hi

I have a bit of a rookie question but is there a way to increase or select the accuracy of an annual daylighting recipee in Honeybee[+]. I am not using the DF (I want results in lux) and not the 3 phase or 5 phase because I don’t have a BSDF. In the legacy version, we can pick ab, ad etc and this is what I would like to do with Honeybee[+] too. There is a component for H+ radiance parameter grid based but the only output I could connect is dmtx. If this is how to do it? And if so, where can I find an overview of the inputs I need to write in the dmtx input text and ranges of values? I have never used Radiance directly and I’m afraid I don’t know much about how to find these parameters.

Thank you
Ellika

1 Like

Hi @EllikaCachat, so there aren’t too many parameters to be considered for HB[+] . Based on what you described, I am assuming you are tracing rays from the sensor points to sun and the sky to calculate illuminance. Then inputs that are relevant are:
-ab: Ambient bounces, Higher the better.
-ad: Ambient divisions, Again Higher the better.
-lw: Limit weight, This should be a value that is 1/-ad and I believe this is sent internally by HB[+]

There are some additional parameters related to direct source sampling (for the solar discs) that need to be set ensure that the deterministic results are repeated exactly for each simulation. These are -dj, -dc and -dt (if I remember correctly). These too are set internally by HB[+].
Finally, the -c option in rcontrib, which is what HB[+] is using to run all the Monte Carlo raytracing, is to be set to 1 for illuminance-based simulations (which is also set by default).

Regards,
Sarith

PS: For the images that I had generated during my dissertation work, Mostapha had created a nice-little interface for comparing the impact of the simulation parameters on results. You can find those here. I think these webpage works better on Chrome than other browsers. Also, as I had mentioned above, disregard the impact of -c parameter as that is irrelevant for illuminance simulations.

1 Like

Hi Sarith :slight_smile:
Thanks for helping.I actually stumbled accross that interface while I was searching the forum for answers about the 2-phase method in Honeybee[+]. I am using backwards ray tracing (or at least I hope so) and I’m trying to compare the results from a workflow that is in honeybee legacy (so using Daysim) to one in H[+] and comparing these to experimental measurements. This is why I wanted to be able to input the same number for ab, ad, and I guess lw too (didn’t know about that one).

Thanks again
Ellika

If you are using Radiance in any of its flavors (Accelerad, HB-Legacy-Daysim, HB[+] etc), then it is backwards raytracing.

Back in 2017, while working on the back-end code of HB[+], we had validated/tested HB[+] against standard raytracing simulation results. (Well, I see that you’ve seen this paper on researchgate, but leaving it here just to complete my explanation!). I didn’t perform a physical validation of the approach, firstly for the lack of time, but also because my assumption was, and still is, that I did likely be retracing the steps from John Mardaljevic’s 1995 study where he validated Radiance against physical measurements by using a Perez Sky Model.
The climate-based sky generated by Honeybee and HB[+] employs gendaylit, which generates a Perez Sky Definition. The daylight coefficient approach, variants of which are employed in Daysim and HB[+], uses a combination of sunpath representations and discreteized sky domes to approximate the Perez Sky definition. What I found, and has also been replicated in tests by a few other people, is that HB[+] performs (marginally) better because we consider more precise sun-positions than Daysim does.

I am not sure if you can get away with using the same values for ad in Daysim and HB[+]. Daysim employs the classic Radiance algorithms involving ambient caching in its raytracing method while HB[+] employs pure Monte-Carlo approach.

In the ambient-caching approach, one can somewhat control the precision of the simulation by setting low enough values for ambient accuracy (-aa) and high values for other complimentary settings such as -ar, -ad etc. Radiance will keep sampling and tracing rays till the prescribed level of accuracy is reached. In pure Monte Carlo approach, there is no guarantee of any precision as the number of rays traced is set by the user. So, there is a risk that if you set low values for -ad you will end up tracing less rays than required.

In my opinion, one way to check if you are running both Daysim and HB[+] to their maximum possible precision levels is to keep cranking up rendering parameters till the results stop changing between successive iterations (i.e. convergence).

Finally, John Mardaljevic has been conducting a tutorial session on ambient calculations every couple of years at the Radiance workshops. The slides from that should provide you with some idea about what is going on under-the-hood with regards to calculation parameters in case of classic Radiance/Daysim. Unfortunately, there are no complimentary explanations for the Pure Monte-Carlo aspect of things, besides this one presentation from Greg from 10 years ago.

Regards,
Sarith

(PS: In case you aren’t already, I would highly encourage you to follow the relevant research by Eleonora Brembilla on this topic.

4 Likes

Hi
Sorry I read this reply a while back but never got around to writing back! So much good information here, I really appreciate it :slight_smile:
I’m not trying to validate Radiance, that would be reinventing the wheel and I doubt I could model anything better than John Mardaljevic. I’m simply trying to assess the accuracy of models in which for example the facade or the shading are a bit weird (or free form type), or defined by an optimization algorithm and you can’t/ don’t want to create a BSDF for each shape to account for it but you use context elements. So in a way knowing that there will be a mistake but looking at how big it is so that if this approach is used in say, early design stages, what to expect as an error % wise, It’s more a bit along the lines of the fit for purpose approach if you are familiar with it. I’m also looking at different levels of complexity to see in some way when the error is just too big and when to stop trusting the simulation results (completely - I guess we never fully trust them but you know what I mean).

However all those ressources you shared are absolutely great and really relevant :slight_smile: so thank you again for that

Ellika