I noticed HB+ uses rcontrib for Solar Access sim which allows the possibility to assign radiance materials to surfaces, unlike the Sunlight Hours sim from LB legacy which was a pure vector based sim without any ray tracing. Which makes me wonder how does it handle different Tvis values for glazings? Does it just ignores the surfaces with the ‘glass’ radainace modifier? Because I did some tests with different Tvis values for surfaces and always got the same results (which kind of makes sense considering we are talking about the number of hours, and not something like radiation intensity etc). Just makes me curious what happens under the hood for this sim in HB+. Any hints would be appreciated.
It’s pretty straight forward. We incorporate the entire geometry of the scene into the calculation. All the materials that will not qualify as glazings,windows etc are made non-reflecting by turning them black and non-specular (this will cut down any diffuse calculations as well as specular calculations). The transmittances of glazings/windows retain their original properties as assigned by the user.
(Here is a partial code snippet: https://github.com/ladybug-tools/honeybee/blob/master/honeybee/radiance/recipe/solaraccess/gridbased.py#L282-L331)
This way, you can iterate through something like different configurations of electrchromic glass to ascertain what value of ASE and sDA would be optimum for your project.
The reason you do get the same values can be attributed to the luminous intensity of the parallel rays from the sun (which is usually too high to be mitigated by the visible transmittance of glass). Try a contrast between 0.01 Tvis versus 0.9 Tvis… if the hourly results are still same, I think we might have a bug.
I wasn’t involved in writing the individual plugins for Gh and Dyn, so I don’t know if @mostapha is changing anything upstream.
Thanks for the blazing fast reply @sarith, and for the explanation too!
So I tried the two different Tvis variants (0.01 vs 0.9) but still get the same results. Please see the attached files. Am I missing something?
ps. Heartfelt congratulations to you for the absolutely fantastic publication about the Matrix-based methods. We printed a copy of it today at the office, definitely looking forward to digging deep into it in the coming days, but at first glance, it looks just excellent! A treasure chest of information!
Actually, the component is doing what it is supposed to be doing (and you are not doing anything incorrect either). I had misinterpreted your question.
The component is just calculating hours of access based on sun coefficients. So, purely based on deterministic testing, if a point “sees” the sun, it will get counted. For ASE type calcs, we multiply the sun-coefficient matrix with the coefficients to derive illuminance. I am not sure if a pure sunlight-only recipe has been implemented inside gh.
Since you brought up the document, there are a few minor errors in it towards the end in Five-Phase and Six-Phase methods. I will be revising those over the weekend (and LBNL should have it up shortly after). The sun calculations implemented in Honeybee are more precise than what is discussed in the tutorial …we trace to actual sunpaths as shown in Figure 17 of the document (instead of tracing to suns assigned as per Reinhart subdivisions).
There is no geometry removal in the process. The results of rcontrib are values between 0 and 1. The result loader for solar access considers any value larger than 0 as 1. In theory its should work fine for any transparent material. Not sure what will happen for translucent materials though. Maybe we should add a warning there!
@mostapha If it’s trans, it’s likely that some of the rays will run into opacity based on openness factor… but I guess that’s how a real fabric will behave as well.
