Annual daylight analysis not working if the windows are split on a facade

assignment (228.2 KB)
tidy (565.8 KB)
Kia ora katoa

I have two students who have encountered an odd error with the annual daylight component in LBT. What they are finding is that it works if the proportion of windows in the wall just creates a single window centred in a facade. They are both creating apertures as % of a facade and using the list option to have different % glazing on each facade.

If they turn on the switch to spread the window as a series of windows spread along each facade, then the annual daylight inside appears to be zero.

Odd, and I cannot find any issue with the model.

This is by way of a plea for help as I cannot figure out the difference between their models and my test cases.

This is an illustration that, where the separated windows become almost continuous, the calculation does proceed. We are doing test runs at a wide grid spacing to ensure quick exploration…

Nga mihi

Thanks in anticipation of your assistance

Hi @MichaelDonn ,
I’m pretty sure the issue is with the grid size. Yours (your students) is so coarse that it doesn’t get the window openings to be accounted for the calculations. This doesn’t happen with the centered only window since it is big enough to be catched by the sample grids.
Try yourself using a smaller grid size.


Kia ora @AbrahamYezioro

The large grid is for exploration purposes - quick response.

The issue occurs when we have small grids as well.

I am systematically breaking down their file myself.


For future information, the issue was to do with the context geometry!

In Wellington we have available 3D files based on LIDAR scans for much of the city. I have allocated 33 sites across the city (one for each student) to be filled by a new Net Zero / Energy Positive Office Building. The goal is to get the students using the LBT suite as far as possible to explore design options for the site in terms of loads, energy and daylight quality.

Given the size of the base files, they are all geolocated so more than one can be assembled to make a particular district. The source of the original observed error is that we have zoomed into the actual location of the geometry and drew our skeleton at this point. In the example that I have just debgged, the location in geolocate mode was around {1.7494e+6, 5.4287e+6, 0} in metres!

Moving the geometry in Rhino to the (0,0,0) origin (without changing anything else) solved the problem.