Annual Daylight analysis (1.3.0), showing different results from "Annual Daylight Metrics" than "Annual daylight" component (in example file)

Hi everyone,

I am getting know the new stable version of Ladybug tools (1.3.0), and I am checking the example files which were downloaded with the plugins. I opened the Annual_daylight files and I have a question about it. For example I want to check the DA and in the example file which is plugged directly into the “Spatial Heatmap” component which shows me the coloured map. I found another component called “Annual Daylight Metrics” where I can also find the DA, but if I plug this one to the “Spatial Heatmap component” I get different coloured map than the previous one.
I took pictures of the my problem.
If I am checking the others ( CDA, UDI, UDI_Low/High with the two different methods there is always a difference between the two coloured map.
Can somebody tell me what is the difference between the two methods (results/ components), or how should I handle this kind of things? Maybe I did something wrong
Thank you in advance for your help and answer!

It looks like you’re plugging in some _thresholds_ to the annual daylight recipe and you aren’t plugging those same thresholds into to “Annual Daylight Metrics” component. It also seems like you are applying a _schedule_ in the recipe but you are not applying the same _occ_sch_ in “Annual Daylight Metrics” component.

You have to make sure that these two parameters match if you want to get matching results since all of the annual daylight metrics are some form of “percent of occupied hours that illuminance conditions satisfy the thresholds.”


I did the same mistake couple months back, assuming that threshold/occ was set, but needs to be set again in new component.

Might make sense to split them up, so both don’t have overlap in internal methods to avoid confusion.

1 Like

The only purpose that the “Annual Daylight Metrics” component serves is if you want to re-calculate the annual metrics using different thresholds or occupancy without re-running the whole ray tracing. So, if the use cases of changing thresholds are niche, maybe we should get rid of the “Annual Daylight Metrics” component or do a better job of hiding it for just those people who want to play with different thresholds. Is this what you mean by “split them up”, @Mathiassn ?


my 2c would be that you could inherit the threshold from the first component and only overwrite if you type something else into the annual metrics component.

So if I set threshold to 100, then keep it there until overwritten. Instead of the annual metrics suddenly assuming 300.

And i’d totally keep the annual metrics component so i can do different outputs. For EN17037 i would need both 100, 300 and 500 lux to show different compliance :slight_smile:


Hi @chris ,
I think the “Annual Daylight Metrics” is a very useful component, especially when working with the EN 17037 (both schedule and thresholds are needed in the standard methods), or when we want to set particular occupancy and thresholds. Please keep it!

Thank you so much guys. Yeah the problem was what you told me Chris (schedule and thresholds differences). Also makes sense when I should use the “Annual Daylight Metrics” as you suggested. Thanks everybody :).

It’s very good to know that the component has use cases that are for code compliance and are not so niche. We’ll keep it front and center, then.

I agree that carrying over the thresholds of the recipe would be nice for certain cases but it could throw a wrench into some others since the results folder currently doesn’t have any information on the thresholds or the occupancy schedule that were used. We could try to search for them in the root of the simulation folder but this isn’t going to exist if someone runs the simulation elsewhere (eg. on the Pollination cloud service or if you run it on another machine and send then send the results folder to someone else to analyze on their machine). And I don’t think we would want the component to fail or to silently revert to defaults when this happens.

Can we just agree that having the two components use matching default values for the thresholds and occupancy is good enough for now? I see that all of the cases where people reported this are with the sample file on Food4Rhino so I could also just set up that sample file to use the default thresholds and occupancy. The more that I think about it, the more it makes sense to me since I also worry about people seeing the thresholds in the sample file and assuming that’s what they are always supposed to use (you would be surprised how often I find this happening with sample files).

Hi @chris totally makes sense to me!

Enjoy the weekend,

Best, M