I need a clarification on whether is possible to made this type of analysis:
Is there a method that automatically manages the inclination of the shades, to block the direct sunlight in a annual daylight analysis? or a metod to find the right shade inclination for each HOY to avoid the direct sunlight?
Hi, @LaFleur - the short answer is yes. The solution will depend on if you are trying to model them as dynamic blinds or find an optimal angle for the whole year and use that. In both cases, it is possible.
the venetian blinds that will be mounted have an automatic cut-off system, therefore I would need that the inclination of the blind in the simulation change autonomously to control the sunlight and see the result inside the room, without predefining a blind angle. Is this possible? Any advice on which component is appropriate to use? or if an example has already been given?
I have one more question. For another Analysis I need to control a blind shade (closed or open, based on how many W/m² the facade receives) for a annual daylight analysis. I saw that the HB Windows Construction component can help me with this, but I doubt if it works only for energy models or also for radiance simulation.
I can’t figure out what position the blinds are when the shade are closed. Are completely closed aka 90° or inclined by 45°?
Isn’t is always equal to the altitude of the sun whenever the blind spacing and the blind depth are the same?
It’s possible to do this but you’d be modeling each of the blind states with detailed geometries, which can be pretty time consuming. I imagine that most Radiance modelers would try to account for this with BSDF files to represent the venetian blinds. I think we are close to releasing a three-phase recipe, though @mikkel knows more about this than I right now.
You can run the annual-daylight (2-phase) simulation with detailed geometry for each blind state. There is no blinds post-processing in Grasshopper yet, but there is a workaround as highlighted here.
However, the 3-phase method is suited for this kind of analysis. The recipe has been in the background while working on annual-daylight with aperture groups and post-processing. But I believe it is ready (or almost ready) to be pushed to Grasshopper. The only issue is again that there is no way of post-processing states in Grasshopper - maybe we should push for this sooner rather than later (cc: @chris).
You can do that. But you also have to model the geometry at all the angles. Each variation is added as a state to an ApertureGroup. Each state will be ray traced individually. If you want a very specific angle of inclination for each hour it can quickly get out of hand. In the list of cut-off angles in your file there are 511 unique angles. If you wanted an exact representation of that, you would also have to ray trace 511 state.
I have set up an example in the attached file. I have four states (angles: 0, 15, 30, and 45). Since the model is not room-based I have to add the ApertureGroup as a light path to the grid. I also added some examples of how to add a schedule to post-processing.
sorry if I answer only now. Thank you first, for taking the time to answer me and edit the file.
I have some question after I check your procedure.
As you recommended, I inserted a list to create each type of slat with the inclination that the slat will have for at least once a year. But if I´m doing so, won’t the analysis be performed as if all the slats were present in every hour, because they are part of the ApertureGroup?.
How can the “States” input of the “Metrics” component, create a dynamic calendar (unless you have to switch off some hours, such as using an occupancy schedule), if the simulation has already taken place?
No. It will do a simulation of each state individually.
As mentioned above the ray tracing of the states are performed individually. This means that when creating a dynamic schedule in post-processing we pick and choose which results (states) we want for each hour. That’s why I previously mentioned the following:
In this case you are not doing just 1 simulation. You are doing 511 simulations.
Remember that the states schedule uses the integer value. The first state is 0, the second is 1, the third is 2, etc. The order is the order at which the states are added to the ApertureGroup. Your states schedule should be a list of integer values.
I tried to let the simulation run on low Radiance parameters (roughly 30 minutes). Below you can see the difference in DA with and without states.
One question about it.
As in the example, in which the slat inclinations of each hour are already known, wouldn’t be possible to perform only one single calculation, instead of having the annual simulation of each single slat state? Is why would be in this case a PIT simulation, because every time the geometrie inclination changes, the simulation has to stop and the calculation times would be too long?
The ray tracing is not done hour by hour. The daylight coefficients are independent of time, and only when the daylight coefficients are multiplied by an hourly sky matrix you will get hourly results. That is why we have to do a simulation of each slat state.
dear @mikkel after the LBT 1.6 update, there is no more “states” input into the Daylight Metrics component and it also doesn’t seem to work well. As you can see, no value comes out of the component. I also had to connect the grid filter input, which didn’t happen before (v1.5.1), otherwise wouldn’t find any grid.
The DaylightMetrics v1.5.1 but works.
How insert in the ApertureGroups, the state where the blinds are off, together with others slat states?
I ask why you told me that this variant of states is called (-1), but I saw that by inserting the -1, the component still creates that geometry, with a negative angle.
The work that @mikkel did on the core libraries to enable dynamic states is all there in version 1.6 but we still have yet to integrate the capability fully into the official LBT Grasshopper components. I think we’ll do this soon but, for the time being, you can stick to using the older customized .gh file and components that Mikkel made for this post. It should all still work with the latest LBT 1.6 core libraries and you shouldn’t have an issue mixing the older custom components from Mikkel’s script with 1.6.0 components.
I saw that with the procedure created by mikkel, an annual daylight is simulated for each type of state blind, but the static state where the blind are off is not simulated. So I can’t get the value of the hours in which there is no need to activate the blinds. How do I activate it? Is there something under my nose that I can’t see?