-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)
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
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
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.
Hi @Aliarch,
Not at the moment. The annual-daylight recipe is the only recipe with this option.
1 Like
Hi @mikkel , i have some questions, thanks for your spending time
- you have mentioned this:
and i want to know the final results, for example DA is average of hours of whole year? im not sure i have questioned correctly or not, but i figured out that the simulation process is done for each state separately and after that the results are averaged as DA for annual. yes?
in fact i want to know about the calculation of this method fundamentally. do you have something describing it .
- other question; the Hb group shades have not been done in Hb 1.6.1? because i have done it but give a error like :
- Solution exception:
The recipe failed to run with the following error(s):
2023-08-06 14:41:14 ERROR: “PrepareMultiphase” failed. See below for more information:
Distributed 30 sensors among 1 grids with 30 sensors each.
Execution Summary
Scheduled 17 tasks of which:
- 6 ran successfully:
- 1 CreateDirectSky(…)
- 1 CreateRadFolder(…)
- 1 CreateSkyDome(…)
- 1 CreateTotalSky(…)
- 1 GenerateSunpath(…)
…
- 1 failed:
- 1 PrepareMultiphase(…)
- 10 were left pending, among these:
- 2 were missing external dependencies:
- 1 PrepareFolderAnnualDaylight(…)
- 1 RunTwoPhaseDaylightCoefficient(…)
- 1 had failed dependencies:
- 1 _TwoPhasePrepareFolder_acc750a6Orchestrator(…)
- 5 had missing dependencies:
- 1 CalculateAnnualMetrics(…)
- 1 CalculateTwoPhaseMatrix(…)
- 1 LetAnnualDaylightFly(…)
- 1 _Main_47d8887dOrchestrator(…)
- 1 _Main_acc750a6Orchestrator(…)
- 2 was not granted run permission by the scheduler:
- 1 PrepareFolderAnnualDaylight(…)
- 1 RunTwoPhaseDaylightCoefficient(…)
- 2 were missing external dependencies:
This progress looks 
because there were failed tasks
- and third question is that this workflow works hour by hour; as a results the states of our objects must change hour by hour. in fact if we imagine to have the changes half hour by half hour it is not possible. am i true?
thanks in advance
Hi @Aliarch,
For each hour it will take the illuminance for the state that you select (or a combination of states if you have multiple aperture groups). Now you have an hourly list of illuminance values for each sensor point. The DA is calculated using these illuminance values, but only for the hours in the occupancy schedule.
No, they are not implemented in the recipe at the moment.
The annual-daylight recipe only works for a timestep of 1 (meaning 1 value per hour). It is possible that this will change in the future but it requires refactoring of multiple elements of the recipe.
hi @mikkel
i have a question. is there any limitation for radiance materials in this workflow? for example translucent materials have any conflict with this workflow?
Hi @Aliarch,
No, that should not be an issue. As long as you can create a valid honeybee-radiance modifier it should work.
2 Likes