I am currently trying to calculate the hourly spatially averaged illuminance following an annual simulation. As an alternative to daylight factor, BREEAM requires the average illuminance to be > 300 lx for at least 2000 h per year.
So far, I’m doing this with the AnnualToData component, with _sel_pts and _all_pts the same list of sensor points, followed by some post processing. However this is very slow given the large grid, while native components, like sDA or ASE, run in a fraction of a second, even though they’re working with the same .ill files.
Any suggestions on how to speed this up?
If there’s a way to directly load .ill files as data trees or matrices rather than using AnnualToData and inputting all sensor points that could work. I have looked into this but it seems they are now stored as numpy arrays which I haven’t worked out how to load into GH.
Hi @jroberts, have you looked into the grid-summary output? @mikkel will correct me but I believe we already run that post-processing in the newer versions of the annual daylight recipe.
Hi @mostapha, I will look into this more on Monday, but it looks like it just calculates the mean/min/max of various daylight metrics.
What I need to do is find the spatial average of a grid for each hour of the year. For example, if I have a grid with 100 sensors, my annual simulation results will be inside a 8760 x 100 matrix… Then I want to take to the average of each row (hour) to give me one value for each hour of the year, so a 8760 x 1 matrix. I’ve been doing this with AnnualToData but this is proving cumbersome, so was just wondering if there’s a better/faster way.
I also found this five year old post, but for legacy.
You might find this exchange I had with the BRE useful…
My queries of the requirements:
“Worst lit point”
please could you clarify if this is the point that receives the least daylight cumulatively over the year, or the point at each simulation timestep that receives the least daylight? E.g. a specific point may receive the least cumulative daylight over a year, but there will likely be hours where it receives more light than other points in the space.
“Average daylight illuminance (averaged over space)”
Please could you explain how this should be calculated? This could be interpreted in a number of ways, for example:
Daylight at each timestep is averaged over the working plane. The number of hours above the target is then counted.
An annual result for each sensor point is calculated from a count of the number of hours exceeding the target lux. The percentage of points exceeding the target hours must be >= the minimum area to comply
An annual result for each sensor point is calculated from a count of the number of hours exceeding the target lux. The results per sensor are then averaged (mean) across the whole space
An annual result for each sensor point is calculated by sorting the annual results from each point from highest lux to lowest, the value at the target number of hours is taken as the result for each point. This is then averaged to give a lux result across the space.
——————
Response:
Please find responses to the two parts of your query below following correspondence with our daylighting specialist.
Re. Worst lit point
The worst lit point should be a fixed point used over the whole year because this is an annual calculation. The calculation process is: place a calculation grid in the assessed space, calculate at each point how many hours in a year the point gets the minimum illuminance required, take the point with the fewest hours as being the worst lit point and check if the number of hours exceeds the guideline.
Re. Average daylight illuminance
Any of options 1, 3 or 4 in your query can be used. Option 2 is not suitable because the calculation must be done space-by-space and the minimum area to comply refers to the percentage of the total floor area of all the spaces that must be assessed (as defined in the methodology section).
Disclaimer: BRE Global endeavours to ensure that our response to your query is appropriate. However this is dependent on the clarity, completeness, context and accuracy of the information given to us by the enquirer.
—————
Note I have paraphrased each email, hopefully not in a way the BRE would disagree with. I’d recommend you also confirm with the BRE before using the approaches set out above.
Hopefully the next version of BREEAM will clear up some of the ambiguity around this credit!
Personally I run some post processing in a Jupyter Notebook on the .npy files output from the annual daylight simulation to get a result for BREEAM. You can use the Pollination python environment to easily have access to the LBT code base to help with handling models / grids etc.
Right now there is no way to do what you want with the LBT components (except the AnnualToData method). If you want to use the honeybee-radiance-postprocess library outside Grasshopper you can use the following code to calculate the number of hours where the average illuminance is above 300 lux.
from honeybee_radiance_postprocess.results import Results
results = Results('your_results_folder')
hours_above = []
for grid_info in results.grids_info:
# get illuminance array
array = results._array_from_states(grid_info)
# calculate average along axis 0 (average for each hour)
avg_ill = array.mean(axis=0)
# calculate number of hours where the average illuminance is above 300 lux
hrs_abv = (avg_ill > 300).sum()
hours_above.append(hrs_abv)
For now I needed a quick fix, so I used a CLI command to convert the .npy files to .ill and simply post processed in Excel , as the files were too heavy (around 500 mb) for Grasshopper to run smoothly on my PC.
A recipe would be wonderful though, but as @charlie.brooker mentioned, BREEAM v7 coming next year may change this requirement (or even use an existing metric).
From what I have seen in the industry, it takes much longer than what we hope for a new version to be adopted. I would say that it is still helpful to support the older version, and then update it to the newer version when available.
, as the files were too heavy (around 500 mb) for Grasshopper to run smoothly on my PC.