Automatic window shade inclination to block the direct sunlight

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

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

-1 will turn the ApertureGroup off, not just the blinds that you added. If you want a state with just the glazing and no blinds you can add an empty state with HB Dynamic State. If you leave it empty it will use the parent’s modifier. Is this what you wanted when the cut-off angle is 0?

Hello @mikkel,
I think I understand and changed the procedure.
I created and merged 2 HB Dynamic State, one only with a empty state and one with 55 inclination angle.
For my schedule a named the hoys wherethe blinds are off with -1 and inserted this state in a sorted states list als first in the index, so the all blind-off state are the index 0, the states where the blind are horizontal open (0°) als index 1 and so on.
So is correct?
rvg_Shade Window Group 08122022_Mikkel_re_(2).gh (123.9 KB)

Hi @LaFleur,

As far as I can tell you got it right.

1 Like

Dear @mikkel , @chris and @mostapha
One of the points that I could not find in this topic is to assign a time step for simulation.
That is, for example, I want to change each state (shade) not every hour but every half an hour. Here, we know that instead of 24 states, we should have 48 states for each day. But the important thing is that the Daylight Metric component must also be equipped with an input (time step)!!! so that the situations can be coordinated with the simulation steps.
If this is not possible, please make me sure that this workflow is only possible hourly (every hour).

regards
Ali

@chris

Hi @mikkel
i have modeled my own and i i wanted to compare between always-on-shading (index 0) with no-shading (index -1) but i am wondering if not only the difference (DA) between them is not equal bu also is vice versa.
in fact the amount of DA must be higher by index -1 reasonably rather than index 0 (shading-on). can you check it? i believe that everything about setting is right. thanks in advance
555.gh (133.8 KB)

and second question is that when i input index -1 solely, the results is going to zero.

Hi @Aliarch,

You have to add your own state for the no-shading case. I believe this is the first state in your setup (index 0) where you got no shades attached to the state, see image below.

Index -1 is a default off-state that you cannot model yourself. The results will always be zero. You should really only use index -1 if you have multiple aperture groups, and you want to see the daylight contribution for the aperture groups individually.

1 Like

thank you so much @mikkel
as a result, i can conclude that when we assign a state without any shade, the first will be 0 (shading less) and other shades will be started form 1,2,3,4… and we no need to input -1. and i checked it and your were right. 0 was shading less. but if we input one HB Dynamic State, -1 will be shading less state.

and another question is that if we want to harvest only the illumination according to the states what action should be done. because this step is before than annul daylight metric component. and i think by default it gives only shading less state.

Hi @Aliarch,

You should be able to modify the other post-processing components as well by adding the states_ option. See an example below for HB Annual Average Values. I added this to the file you share. You can also do it for HB Annual Results to Data if that is what you mean with the question below.

555.gh (139.4 KB)

1 Like