Dynamic Geometry states schedules

Hi @mostapha,

The new Hb radiance is a dream come true.

I was looking at the dynamic geometry components and wondered how to input the schedules at which the different states would be activated. Am I missing something or is it a feature under development?

With kind regards,

@OlivierDambron ,

We currently don’t have any recipes yet that take advantage of the dynamic geometry setup in the newest LBT Honeybee. But these recipes should be added very soon to the development version of the plugin. So yes, it’s under development.

FYI, the dynamic behavior will be just like it is in Honeybee[+] 0.0.06. So the Radiance simulation doesn’t take a schedule and it just computes the relationship between each state of a dynamic Aperture and the test points. Afterwards, you can apply whatever control logic you want and the hourly illuminance will be computed in real-time. This control logic can be a schedule but, more often to mimic real daylight controls, you will pick a point out of the grid to be an illuminance sensor and the hourly value at that sensor will determine the state of the dynamic geometry.

1 Like

Hi @chris

Thanks for all the infos. All the best with the development of those recipes.

It is often the case that daylight simulations are subsequent to thermal simulations, where shading schedules that come out of a thermal simulation inform the daylight simulation, instead of lux values for given points. On the other hand, lux values taken from a sensor inform back the thermal simulation to calculate savings.

I understand that with the new workflows, a simulation will run for the entire year (so far) and for all states (later on), with potentially heavy matrix multiplications.
Although simulations now run much faster and can get smoothly parallelized, I wonder if given a EN 17037 calculation with 2200 hours only and several states, that it wouldn’t be faster to trim all matrices first, as all the 0 values corresponding to nighttime and the other ~2200 unused values account for a lot of disk space and running time.

With kind regards,

We will definitely have official support for this soon. You can actually hack it right now by filtering the input Wea object using the Ladybug Tools core SDK method here:


The only reason why we don’t have it in the components right now is that is messes up the (currently simplistic) result-parsing component. But, once we have this result parsing in a better shape, we’ll expose the ability to filter the Wea by hoys on the components to keep the study smaller.

1 Like

many thanks @chris, this will do for now. I’ll find my way with reading results.

All the best with the developments!

1 Like