Calculating Average, Min and Max Values for Sensor Grids are Now Part of Annual Daylight and Daylight Factor Recipes

Hello :pollination: community,

One of the most common uses of Pollination cloud computing has been to run parametric studies to generate parallel coordinate charts like the one in DesignExplorer. The parallel coordinates chart works best for a single value for each study. As a result, we have seen thousands of studies where users used Grasshopper to download the raw results to calculate the average, minimum, and maximum values for each run.

We are happy to announce that we have updated the annual daylight and daylight factor recipes to output a summary that returns the mean, minimum, maximum, and uniformity ratio of the metrics for each sensor grid. Here is an example output for a study with 2 sensor grids:

The new recipe output is shown below. One can select the desired item, e.g., the average daylight autonomy, and use native Grasshopper components to split the string and get the values. A sample of the workflow below can be found in the attached file: (8.0 KB)

We have also added a new input that allows the user to add additional customized grid summaries to the recipe.

Finally, as part of this process, we have also made a few changes to the annual-daylight recipe to provide a quicker version of the recipe for annual metrics.

For medium-sized models, the new annual-daylight recipe saves you 20-30% of the time, and for large models, it can save you 50% of the time. For huge models, it can even save you more than 80% of the time. In terms of CPU usage, it saves 15-30% regardless of the model size.

annual-daylight vs. annual-daylight-enhanced

Until now, the default annual-daylight recipe in the Pollination ecosystem has utilized an enhanced version of the 2-phase method, in which three separate calculations are put together to simulate the direct sunlight contribution more accurately. However, for many users, the accuracy of direct sunlight is not always important. After running several comparative studies we decided to change the default annual-daylight recipe to use the basic 2-phase method, which consists of a one-step calculation. This approach provides a quicker version of the recipe without compromising the accuracy of the results.

Users who need to use the more accurate calculation of direct sunlight can use the annual-daylight-enhanced recipe.

When should one use the annual-daylight-enhanced recipe?

For most studies the default annual-daylight recipe is appropriate but if you are not an expert on the topic, you might not know when the right time is to use each recipe. This section helps you to identify those cases.

To help decide which recipe to use you can ask yourself the questions below.

  • Do I need to simulate aperture groups, and customize the post-processing with schedules for each aperture group?
  • Do I need to examine the hourly illuminance values?
  • Do I need any metrics calculated on the basis of the direct illuminance, e.g., Annual Sunlight Exposure (ASE)?
  • Do I need to examine the direct illuminance at all?

If you answered yes to any of the questions above, you should use annual-daylight-enhanced. If you are still unsure if you should use annual-daylight or annual-daylight-enhanced create a new topic on the forum or leave a comment here and we can help you to pick the correct recipe for the job.

Scalability on Pollination Cloud

The structure of the new annual-daylight recipe results in better scaling of simulations on Pollination Cloud. Below is a graph that shows the duration of the for an increasing number of sensor points while keeping the CPU count fixed. While the duration can be lowered for annual-daylight by increasing the CPU count as the model grows larger, the same cannot be done for annual-daylight-enhanced since the post-processing is a bottleneck that is executed on only one CPU. This becomes a problem as the number of sensor points increases.

Customized grid summary with new recipe input

The new version of the recipes has an additional input which makes it easier to do basic summarized post-processing for each sensor grid. This input works similarly to conditional statements in Ladybug components. For example, you can calculate the % of sensors with daylight autonomy higher than 80 as part of the recipe post-processing.

By default, the mean, minimum, maximum, and uniformity ratio (minimum / mean) will be calculated for each sensor grid. It is possible to customize these calculations by percentages above or below a threshold, or percentages within a range. The input can be added as a JSON file or a string input; see examples below.

These calculations will be presented in a CSV file as a recipe output.


We have adopted JSONSchema specifications for defining the threshold inputs. For example, to calculate the percentage of sensor points above 75% of each of the five annual daylight metrics, e.g., > 75% DA, you should use the following input.

        "minimum": 75

If you want to add another condition, e.g., 50 <= DA < 75, you can expand the input by adding another item to the list.

        "minimum": 75
        "exclusiveMinimum": 50,
        "maximum": 75

:information_source: The new recipe input is also added to the daylight-factor recipe.

Multiple tags for each recipe

Before this release each recipe would come with two tags. One was the default recipe versioned as x.y.z and another one with and additional -viz. The new release has an additional tag for -full. This change allows you to pick the right recipe for your case based on the required inputs for your studies.

You can see the different tags and their output in the table below.

Tag DA CDA UDI UDI (Lower) UDI (Upper) Grid Summary Visualization Results folder
x.y.z :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :x: :x:
x.y.z-viz :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :x:
x.y.z-full :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark: :white_check_mark:

The five annual daylight metrics are:

  • DA → Daylight Autonomy
  • CDA → Continuous Daylight Autonomy
  • UDI → Useful Daylight Illuminance
  • UDI (Lower) → Useful Daylight Illuminance (Lower)
  • UDI (Upper) → Useful Daylight Illuminance (Upper)

Many users will not need the results folder, which is mostly used for customized post-processing, or recalculating the five annual daylight metrics with different thresholds or occupancy schedules. Having these different tags is particularly useful for cloud simulations since the results folder is the largest output in terms of disk space and takes the longest time to process at the end of the cloud run.

A comparison between the -viz and -full tags can be seen in the graph below. The only difference between these two tags is the restructuring of the illuminance results to a results folder and zipping the results folder as an output. For smaller models, this is not noticeable, however, as displayed in the graph it can double the duration which is not desirable if the user does not require the results folder. Previously the results folder was not optional. It was a recipe output whether you wanted it or not, but now it will be an option.

We are looking forward to hearing your feedback.

Happy Pollinating! :pollination:


Beautiful work guys! Any changes that might reduce computing time is welcome :wink:

I suppose that the annual-daylight vs annual-daylight-enhanced recipes have only been adopted for Pollination recipes at the moment, right? Will these changes also be applied to the LBT components?

It might be wise to add this discription or an abbreviated version of it to the LBT component


Hi @labrosse,

We have talked about adding a boolean toggle to the HB Annual Daylight component so you can switch between the two recipes. But right now you can only use the annual-daylight-enhanced recipe in the LBT component.

Amazing work! Thank you so much for the all the time saved!

I’m regularly challenged by the disk space needed for a simulation. With the 2phase method, the files often add up over 40-60 GB easily and could cause the simulation to crash once the disk is full. I suppose that the new recipe for annual daylight will be lighter, so that’s a major +.

I was wondering if it would be possible to also include some compression in the folders of the enhanced recipe?

With kind regards,

1 Like

Hi @olivierdambron,

Since the direct illuminance is not saved in separate files – it is in fact not even calculated – the results folder of the new recipe will be half the size.

I have an idea of how to only save the total illuminance in the results folder by a boolean recipe input. I am however not sure if it will work in practice. But that could also reduce the results folder to half the size.

hi @mikkel

Perhaps we could limit the number of decimals in all calculations to say 2 digits? or perhaps let user control that?

Hi @olivierdambron,

With NumPy we cannot really do that since the arrays have a data type, which in the recipes and post-processing is float32. It is not possible to just round the arrays by two digits and save it to a npy file - the file size will remain the same. It is possible to use float16 instead, however, the calculations will be slower, and there will also be some loss in accuracy (which is probably negligible for annual metrics). At some point I can check if it will work in the recipes.

1 Like

I would suggest making this adjustment in an additional post-processing in the app or the Grasshopper script and keeping the recipes as they are. Would that work in your workflow, @olivierdambron?

Hi @olivierdambron,

I was too fixated on the results folder itself, and I did not notice that we can also significantly reduce the overall size of the project folder by changing a few steps in the recipe. This will only affect the initial results, which are also part of the project folder.

The change is available in the latest version of annual-daylight-enhanced on Pollination.


2 posts were split to a new topic: Add results summary to the EN17037 daylight recipe