Hello! Now that dynamic shade groups are implemented 1.5.(THANK YOU!), I have a question that relates back to an older post. For context I am working on assigning different transparent materials to tree canopies based on the month of the year and the type of tree (publication in review). I had been doing this by running monthly simulations and swapping the material file for the tree surfaces (as HB faces), but I would prefer to run just one annual simulation where the tree surfaces are all treated as shades and placed in dynamic shade groups (based on the type of tree).
So, I understand from the template file how to assign dynamic states to apertures and shades, but I do not know what assigning these states actually means in terms of time steps. In short, how does the simulation know when to change states and can this be controlled by time step similar to assigning an occupant schedule? Should I just assign a state for each shade for each time step using a repeat component?
I glanced at the source code for this section of Honeybee but didn’t find much beyond the state_index and the json file that is created. Please let me know if there is any control in Honeybee that I am missing or if this goes deeper in Radiance strings.
From the below post it seems that there is no schedule. Rather the inclusion of states just instructs the recipe to iterate the simulation for each state and then in post processing the various results files can be filtered and put together depending on whatever logic you want to implement. Is this the case?
You are a little too early. While the functionality of Dynamic Aperture Groups is implemented in the annual-daylight recipe in the latest development version, the Dynamic Shade Groups are left out of the simulation at the moment.
Yes, it will be similar to assigning an occupant schedule, where each Aperture/Shade Group can be controlled on time step basis. State schedules will be applied in post processing, so as you figured out, this is not something you should worry about when creating the model.
A note (on Dynamic Aperture Groups) for those reading the first line of my answer:
The post processing* is not yet implemented in Grasshopper, but if you include Dynamic Aperture Groups in your HB Model, the annual-daylight recipe should run simulations for each group individually. The results folder should look something like this if groups are included in the model.
*EDIT: Here I mean post processing of aperture groups. A static model will still work in Grasshopper as previously. If not, then it’s a bug.
Thank you @mikkel for the reply. I think this constitutes a solution. If shade groups are in fact not supported at this time then the 1.5.0 release post should probably be amended as it indicates that they are ready to go, unless I am misreading something and that only applies to EnergyPlus recipes. I think I could just as easily apply these as aperture groups and handle the post-processing with my own state schedule outside of grasshopper anyway.
Ladybug Tools for Grasshopper 1.5.0 Release Dynamic Shades and Windows in Thermal Mapping - The previous release of the LBT plugin included a major refactor of all thermal mapping recipes, which made them “better than Legacy” but still not “complete.” With this release, we have added support for dynamic window and shade constructions, which officially completes these recipes and means that all attributes of Honeybee models are fully accounted for in the thermal map results. The new dynamic capabilities can be used to study the impact of a variety of strategies on thermal comfort, including retractable awnings, deciduous shade trees, electrochromic glass, and manual or automated blinds/shades.
I think aperture groups should work for your case. One thing that I didn’t mention is that the newest version of the annual-daylight recipe stores the results as NumPy files. There is a Results class in honeybee-radiance-postprocess (still WIP) with several methods such as daylight autonomy and point-in-time. If you want to give it a try I will be happy to help if you need anything, and if something is absent we can add it, if it makes sense to expose it in the Results class for all users.
I am not well versed with Python. Is there a way to parse the aperture groups data inside grasshopper using the [HB results to data]? Or if you could suggest some method in which I can bring the data for all aperture groups in grasshopper, so I can postprocess it with a grasshopper logic.
It is not possible right now, but in the near future there will be an option to use schedules for the different aperture groups. In the prototype example below I change the states for the skylights, either with a static schedule or dynamic schedule (8760 values). It should be possible to add this functionality to the post processing components in HB-Radiance.
I think at the moment it is not worth doing so. You would have to translate all the .npy files to text files so you can read them into Grasshopper.
Yes, I think you misunderstood that the LBT 1.5 announcement for dynamic windows and shades is ONLY for EnergyPlus and thermal comfort mapping simulations. Dynamic objects in EnergyPlus are a little simpler than the Radiance groups here since you know the control strategy of the windows and shades as the EnergyPlus simulation is running. So it doesn’t necessitate the sophisticated postprocessing with numpy arrays that @mikkel is doing here.
It failed because you have one empty state added. When the state modifier is left empty it will default to the modifier of the aperture geometry. In this case it’s the default glass modifier. So the issue is really not that you left the state empty, but rather because it’s not possible (for now) to mix BSDF modifiers with other Radiance modifiers for the same aperture group.
Actually it is possible as long as the first state is a BSDF state. I have identified why and where in the code it causes issues, but I will wait to push the solution until I have checked that it does not mess up anything else. For now you can just swap the order of the glass state and the BSDF state.
Could you please help me why this doesnt work for Dynamic Aperture Group? (It works fine by bypassing this feature). What does make it not working for multiphase simulation?
