Daylight Factor rounded values

Hi @sarith,

  1. In the daylight factor recipe I can see that the SKYILLUM is set to 100 000.

Following this document:

“6.3.3 Example: CIE Overcast Sky Defined by Its Horizontal _
The preceding example showed how to generate a brightness distribution based on
the standard CIE overcast sky model. The absolute brightness of the sky, however,
was normalized for the purposes of illustration. Furthermore, the input and output
were in units of radiance or irradiance. Before we can tackle real-world problems,
we need to be able to relate the more usual daylighting quantities of luminance and
illuminance to the radiance and irradiance inputs required by gensky. Recall that
although the _
_ system calculates in units of radiance/irradiance, we will use

a constant value for the factor to convert these to luminance/illuminance, or vice
Daylighting practitioners commonly describe a sky in terms of the diffuse hori-
zontal illuminance that is produced by that sky. Recall that the CIE overcast model
does not include the sun, so here the global horizontal illuminance will be the same
as the diffuse horizontal illuminance. The CIE overcast sky can therefore be fully
characterized by the horizontal illuminance, usually given in lux. **A realistic hori-**
_zontal illuminance for a (brightish) overcast sky is 10,000 lux.

Is this something taken into consideration further in the code ?

  1. After running a test case, I see that DF values are rounded with no decimals. Is this intended? Any way I could change this without making a mess in the code?

Kind regards,

Hi @OlivierDambron,

  1. Since daylight factor is a division of illuminance at the sensor point by the sky illuminance the value of 10,000 vs 100,000 doesn’t make a difference in the final results. The reason to pick 100,000 over 10,000 is what is mentioned in this discussion:

  2. It is intentional. We’re using a software with %5-10 error because of the stochastic model of calculation. We had this discussion early on and decided to round all the numbers which will saves us memory (integer vs float) and is fine from the accuracy point of view. If you want to get the original values you should change these line.

Keep in mind that this method is used by all the recipes and it will make all the results to be float instead of integer. If you only want to change it for daylight factor it is in line 276.

Now why do you need the float value?


Hi @mostapha,

Many thanks for your answers.

I’m trying to get floats because when complying with the ‘Code of practice for daylighting’ by the British Standard 8206/2: minimum values of Average Daylight Factor (aDF) for housing are 2% for kitchens, 1.5% for living rooms and 1% for bedrooms.’

One decimal will do.

Hi @OlivierDambron, Great to know! I’ll adjust this for the next release. Maybe we add an option for users to control rounding.


Hi @mostapha,

I’m new to Honeybee[+] (and coding in general too), to obtain floats for the daylight factor you mentioned to change line 276 from the analysisgrid python file…

Do I simply change it to this? (removing ‘int’ )
values = (tuple((float® / mode) for r in
for count in xrange(end))

Since it is not giving me any different results, I would like to know in what it exactly has to be edited to.

Thank you in advance!

Best regards,

I believe that If you update your HB+ installation to the Github version, you should get floats only.

1 Like

I’ve just installed Honeybee[+] 0.0.04 downloaded from Food4Rhino. Still seeing integer values for daylight factor. Am I doing something wrong or is there another version I should be using?