Automatic window shade inclination to block the direct sunlight

Hallo dear community,

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?
03

Any existing example to study the procedure?

Thanks and best regards

2 Likes

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.

Dear mostapha thanks for the answer.

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°?

Thanks in advance for the help

The angle is as it comes from the blinds material component. The default being 45°.
-A.

1 Like

Thanks dear Abraham, now is clear but my doubt now if the component WindowsConstrShd work for Radiance simulation, or only for E+ analysis.

Any advice about this?

Thanks and have a good day

Hi @LaFleur ,

It works ONLY for E+ simulations. For Radiance you need to model real shades. Try the HB_LouverShades component. It will give you geometries that Radiance understands.

Can’t help you with the other question … though will be happy to see the solution.
-A.

1 Like

Dear @mostapha, I found myself facing this issue and make me strange not to find a component that calculate the cut-off angle of a slat for blocking the direct sunlight. Or simple didn’t find it?

@AbrahamYezioro I would to ask: would be correct to analyse Daylight, taking in consideration blinds/louvers, etc only with a 2-Phase Metod?

Greetings

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.

1 Like

Dear Chris, I don’t want to be wrong, but I don’t think so, unless I misunderstood your answer.
I attached a help for the cut-off angle equation


I am little strange that this function is not already present in a component, also because it is a type of analysis that is increasingly requested and is included in several regulations.

Thanks for the info.

Thank you always for your availability
Bestia regards

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).

3 Likes

Dear Mikkel, Chris, Liam and Professor Yezioro, many thanks for the discussion and for the significant Infos.

@mikkel so now work only with blind on, blind off, according to your script?

If I have a list with the angle of inclination that the blinds must have for each hour of the year, at the moment I cannot integrate in a annual daylight analysis?


Shade Window Group.gh (97.7 KB)

Thanks for all
Best regards

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.

Shade Window Group 08122022_Mikkel.gh (111.2 KB)

2 Likes

Dear @mikkel,
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?

I still ran the test, as your recommendation, and this error comes out “fail to compute annual daylight metrics”
Shade Window Group 08122022_Mikkel_re_.gh (153.3 KB)

Best Thanks and happy holidays

Hi @LaFleur,

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.

Without states (always default state)

With dynamic states schedule

Here is the attached file. I changed the schedule so it matches what you want to achieve (I believe).
Shade Window Group 08122022_Mikkel_re_.gh (149.5 KB)

6 Likes

Dear @Mikkel,
is now all clear.
As always, thanks for your maximum availability and clarity in the explanations.

Best regards and have a happy 2023!!

1 Like

Amazing and very interesting @mikkel.

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.

1 Like

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.


Is there a new way for this procedure?

I have a last question about the states.


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.

Thanks and have a nice day

Hi @LaFleur ,

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.

2 Likes

wonderful @chris, this would be great!!!

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?