Hi Chris,
I am working on a daylight-model validation using indoor measurements recorded approximately every minute. I came across these previous discussions:
https://discourse.ladybug.tools/t/finer-timesteps-do-not-work-in-hb/9375
https://discourse.ladybug.tools/t/sub-annual-daylight-simulation-with-timestep-other-than-1/17247
My understanding from your previous replies is that the main limitation of sub-hourly Annual Daylight was the annual-metrics post-processing, rather than the Radiance calculation itself.
I tested this with the current HB Annual Daylight component with enhanced_=True, using a custom WEA with 120 one-minute timesteps.
The recipe failed at CalculateAnnualMetrics with:
IndexError: boolean index did not match indexed array along dimension 0; dimension is 120 but corresponding boolean dimension is 2
However, before that failure it had already generated sun-up-hours.txt with 120 timestamps, sky.mtx with NCOLS=120, total_sky.ill with NROWS=56 and NCOLS=120, and result arrays with shape 56 × 120.
I repeated the test after deliberately removing five minutes from the WEA. The same thing happened, but all outputs then correctly contained 115 timesteps, including the expected gaps in sun-up-hours.txt.
So it seems that the core calculation is handling both minute-resolution and discontinuous WEA data correctly, while the failure occurs later in the annual-metrics post-processing.
For my validation I only need the .ill results and sun-up-hours.txt, not DA/UDI.
Would it be reasonable to use these outputs directly despite the post-processing failure?
I also noticed that the underlying annual-daylight-enhanced recipe exposes a timestep input up to 60, while the Grasshopper component does not. Would invoking the recipe directly with timestep=60 be a better approach?
Thanks!