I’m recently trying out the Pollination plugin for Gh to run the LEED Option 1 daylight workflow. I’ve been following your videos for the same.
I face an issue when trying to run the HB Automatic Aperture Group component. It throws me an error, tells me that the model must at least have one aperture, although I’ve passed the apertures to the model correctly. I tried to see if it’s a BC issue, but the apertures rightly have ‘outdoors’ as the boundary condition.
Have you come across this issue before? Would really appreciate some help!
I built the script starting from many “HB Face” components. Is it the case that if it’s not room-based, then the automatic aperture grouping doesn’t work?
Yes, that is correct. The reason for this is that the whole aperture group concept is based on the light_path property of the sensor grids. This property is found by tracing the path of light from the room to the exterior (this is why the BC must be Outdoors). This operation takes place when writing the model to a Radiance folder, i.e. when you run the recipe, and it is a purely geometrical calculation (this is why it must be room-based).
As you can see in the image below, the light_path property is not set for the sensor grids after they are created. You can set this property manually – which you are not really supposed to do – in which case it will override the automatic tracing of the light path. I have tried to do this for annual-daylight-enhanced, but never leed-daylight-option-one. It should however work the same since both recipes share the same base recipe as a dependency. When doing this you have to create the aperture groups manually as well with the HB Dynamic Aperture Group component.
If you are unable to create rooms, and you want to give the other workflow a go, I can help you set it up in Grasshopper. I will not promise that it will work!
Ohkay, now I get why it is this way, thanks for the explanation @mikkel
I’m afraid the workflow I’m trying to set up can’t start with an HB Room, since I have a lot of face-based façade customisation logic upstream. So I think I could use some help with the other workflow, if you could try to set it up
Also, if you’ve already made a tutorial on how to use the HB Dynamic Aperture Group component, please do point me to it, I’ll try to go a little ahead with it
You simply add all the apertures that you want to group, and then give the group a name (no duplicate group names and no repeating apertures in multiple groups!). You should not touch the states_ input since we don’t need it for LEED Daylight Option I. The output of the component is a list of apertures that you can connect to the model like you would do with regular apertures.
When the groups are set up we can start editing the sensor grids.
@mikkel I’m now working on a script that that starts with a “HB Room” to build the model. The automatic aperture grouping now works here in this case, but for some reason, the recipe (LEED Daylight Option 1) doesn’t give back any valid result. It shows the DA as 0% (floor_area_passing_sda as 0 m2), and the ASE also as 0 (floor_area_passing_ase as the entirety of the floor area).
But if I pass the same input model without the Aperture grouping, the results are sensible and representative (~63% sDA, etc.) and I could verify the same with the Annual Daylight recipe as well.
Am I doing something wrong with the aperture grouping component? Could use some help with solving this
The latter will set the room_identifier of the sensor grid, which is important when there are aperture groups in the model. This way we can link the aperture groups in a room to the sensor grid with that room identifier.