Incorrect solid angle in gendaylit diffuse normalization factor?

Hello,

I’m looking at the Radiance source code from 2019 ( [https://github.com/NREL/Radiance/blob/master/src/gen/gendaylit.c] ), particularly the gendaylit function.

To get the normalization factor for diffuse light, integ_lv multiplies a buffer by (2*pi/144).

It seems like the buffer should be multiplied by the solid angle represented by each of the 145 azimuth and zenith angles (phi_o, theta_o) . Given that there are 145 distinct points for which the luminance is calculated (and 145 equal solid angles), I’m wondering if this value should be (2pi/145) rather than (2pi/144).

Can anyone say whether this has been changed since 2019? Or if it is in fact correct as 144?

Grateful for any help. Apologies if this has already been discussed elsewhere.

Thanks,

Annie

I don’t know the answer to this, but @Jan_Wienold might be able to help.

1 Like

Hi Anni and Greg,

This part of the code was never touched since it was released from J-J.
Delaunay in 1994.

I don’t have so much time to check the code in detail, but from a quick
look it seems you are right and this looks like a bug in gendaylit.

OK, I’ve updated the source to correct the factor, which will have a 0.7% effect on the sky normalization.

1 Like

Great! Thanks very much for your responses Greg and Jan.

To me it seems the solid angles are still not correct. The sky patches in the Tregenza dome, do not all have the same solid angle, the size of the patches depend on the zenith angle. As far as I can tell “integ_lv” in gendaylit simply assumes all patches are of equal size.

Perhaps this is related:
https://discourse.radiance-online.org/t/gendaylit-vs-gendaymtx/3455/6
Looking at the code of gendaymtx it does take into account the solid angle for each patch.

You are probably correct, though I hesitate to change code I didn’t write unless I understand it fully. Perhaps @Jan_Wienold has a clearer notion, though I know he didn’t write the original version of gendaylit, either.

Yes, I agree that it looks like the it uses the same solid angle for all patches.
I quickly checked the gendaylit-code and we basically need to include:

          solid_angle_tregenza_patch = 2*PI*(sin(theta*(i+1)) - sin(theta*i)) / n_row_patches   )

However, since this code is not originating from me, some small things have to be checked first and considered. (e.g. the equation before is valid for the borders of the patches, but as far as I can see the angles defined in defangle_theta are in the center of each patch. And the i in the equation before is not the running theta of each patch, but the row counter. And the zenith-patch has to be treated correctly.
I can look into that in the next days, but would need someone to check my code-changes then before sending to Greg (@bart ? other volunteers ? ).

Sure, I can review the changes.

Regarding the suggested correction, is θ the zenith or elevation angle?
I would have guessed zenith, but in that case I feel the correction should be:
Ωp=2π[cos(θ{i})-cos(θ{i+1})]/Nb{i}
with Ωp the patch solid angle, and Nb{i} the number of patches in the i-th band

Derivation:
The solid angle of a cone with opening angle θ equals
Ω=2π[1-cos(θ)]

Thus the solid angle of a band between θ{i} and θ{i+1} should equal
Ωb{i}=Ω{i+1}-Ω{i}
Ωb{i}=2π[cos(θ{i})-cos(θ{i+1})]

the formula is for an altitude angle. If the angles are from the zenith ( I did not check the code completely, just looked briefly at the subroutine), then it is the cosine instead of sinus. I’ll look into this in the next days, I’ll let you know when I’m ready.

Hello

Please, could you have a look to the daynumber variable when the Sun position is provided ? This variable is not initialized

Many thanks !