Annual daylight issue with 1.2.2 version

Dear users,

I am now testing the latest annual daylight component (v1.2.2), and faced some issue as below.

  • When I assign annual 3650 hours (8:00~18:00) to hoys of [HB Wea From EPW] component, final .ill file not shows 3650 hours results for each point.

  • How the annual daylight component define the sun-up-hours? It seems different from total hours which has >0 global horizontal illuminance.

  • DA results from [HB Annual Daylight] component and [HB Annual Daylight Metrics] component is different even they have same schedule.

  • I have assigned two different states to aperture group, but there is only one annual result. How the calculation consider the aperture state?

Below attached is the test file which presents the mentioned issue.
test.gh (94.0 KB)

Thanks in advance for the advice.

Hi @gogog ,

Thanks for reporting the bug with the Daylight Autonomy output directly from the annual daylight component. The “HB Annual Daylight Metrics” component was returning the correct values that respected the occupancy schedule whereas the direct output of the “HB Annual Daylight Metrics” component had a bug that caused it to ignore occupied hours when the sun was down. I just merged a fix for this and you should be able to get it with the LB versioner component in an hour or so:

To answer your question about how the sun-up-hours are computed, we do so using the Ladybug Sunpath module. Any hour where the solar altitude is above 0 counts as a sun up hour. The only reason why we do this is that the Radiance calculation is significantly faster when we only run it for daytime hours and just ignore the nighttime. Also, the EPW illuminance isn’t used at all by Radiance. All Radiance calculations are done from the EPW’s radiation/irradiance data and Radiance has a built-in luminous efficacy model to convert between irradiance and illuminance.

We currently don’t have any support for dynamic groups (or BSDF materials) in the LBT plugin yet but I know @mostapha is working on this one and it will be there eventually.

1 Like

Hi, Chris. Many thanks for your kind reply!

Hi, @chris
regarding to the sun-up-hour, I still have some query on it.

As attached file, annual daylight simulation resulted 4393 sun-up-hours.
But with LB Sunpath component, there are 4438 hours which have sun position, still cannot match with above data.

test222.gh (53.7 KB)

@gogog ,

This is most likely because, by default, the Ladybug Sunpath component produces sun positions that fall on the hour (eg. 11:00, 12:00, 13:00…). However, when you do a daylight analysis, you need to align the sun positions with the radiation/irradiance data in the EPW file and this means using sun positions on the half-hour (eg. 11:30, 12:30, 13:30…). This is because the radiation values in the EPW file are the accumulated radiation over the previous hour. So the sun position that best aligns with a given EPW radiation value is that of the previous half-hour.

All of this is to say that I think you will get matching numbers of sun-up hours if you plug in decimal hoys (eg. 0.5, 1.5, …) to the Ladybug sunpath component instead of whole numbers.

Hi, @chris Thanks again for your detailed explanation