Hi all. I’m working with the new LBT 1.5.0 version. On the way to split the direct and diffuse radiation, I found there are two ways in the figure below that
Although I guessed direct_normal_rad has nothing to do with diffuse, I found there are differences between the diffuses of “1. No replace” and “2. Replace” .
The gendaymtx Radiance command that is used under the hood of the “LB Cumulative Sky Matrix” component uses the location to figure out where the sun should be in the sky and then uses the combination of direct and diffuse values to figure out how cloudy the sky is in order to distribute the solar energy over the sky patches. So setting direct radiation to zero and changing all of the diffuse radiation to be for a cloudy sky will change the distribution of the diffuse radiation over the sky patches. You can imagine that, for a sunny sky, there would be more diffuse radiation closer to the disc of the sun than there would be on the other side of the sky. For a cloudy sky, the radiation will be much more evenly distributed across the sky dome.
Yes, I would not recommend zeroing out the direct radiation before you generate the cumulative sky since this means you’re creating a cloudy sky that does not exist in the climate you are studying.
If you’re trying to run a study that only looks at the diffuse component of the sky (acknowledging that the direct component is still there but you’re just not studying it), then you can create the sky matrix as you normally would but deconstruct it with the LB Deconstruct Matrix component, zero out the diffuse sky patches, then reconstruct the matrix with the LB Construct Matrix component. This is similar to the methods used to create a “Radiation Benefit” sky that you see in this sample file.
This came up again recently when @remyweather asked me how to do the workflow with Deconstruct/Reconstruct Matrix. So I thought I would add a sample file to this discussion in case anyone wants to do this on their own:
Hi. We are trying to conduct daylighting/PV/energy balance analysis of a reference office using a glazing with special micro-optics that treat very differently direct and diffuse light. This component is actively tracking sun direct light, so the BSDF itself changes continuously as a function of sunlight’s angle of incidence. This would require a huge amount of .xml BSDF files and switch between them dynamically, which I assume would be too computing intensive. Furthermore, the BSDF patches would need very fine around the sun (tensor tree), which would make a ton of data.
Thus, I have come to the conclusion that we will need to split simulations in direct and diffuse components, and then merge results. This would allow us to use a single BSDF for direct sunlight, and another BSDF for diffuse light, both with coarse resolution.
If I understood your post well, we can do this in Ladybug simulations using the Deconstruct/Reconstruct Matrix approach.
Which would be the best ways to do the same in Honeybee daylighting/energy simulations with wea and sky objects?
Thank you in advance for your light here!
