Automatic window shade inclination to block the direct sunlight

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

Hi @mikkel ,
Checking this discussion and this other one, i have a question: Is the implementation of the states be included in the HB components or they are going to be only for the LEED recipes in pollination?
I also think that the dynamic_geometry.gh example will be extended to the use of the states and post-processing results (or adding an additional example to the Radiance folder).
Am i misunderstanding something and those are already there?

Thanks!!
-A.

1 Like

Hi @AbrahamYezioro,

Yes, the plan is to have the states option for the post-processing components in Grasshopper. I want to refactor the states-related code in honeybee-radiance-postprocess to make it more robust. This should also help creating a more user-friendly interface in Grasshopper.

I think once it is available in Grasshopper some sample files are a good idea, either extending dynamic_geometry.gh or a separate file.

3 Likes

Thanks @mikkel ,
Looking forward into this.
-A.

thanks @mikkel
it worked however for other components didnt work for example HB Annual Cumulative Values )
—, maybe because of exact place of modified code.
by the way, i want to work with HB Automatic Aperture Group but it is red component with error 1. Solution exception:invalid syntax. do you know what is that problem?

Hi @Aliarch,

The attached component should work:
cumulative_values.gh (7.2 KB)

Thanks for reporting the issue about HB Automatic Aperture Group. I pushed a fix, and you should be able to get it within an hour by updating your core libraries with LB Versioner.

1 Like

Hi @mikkel
i want to know the cut-off schedule is possible for other component such as HB Annual Irradiance and HB Imageless Annual Glare ? i tried once on the Annual Irradiance but i think it dosent work according the states.