I was not trusting the results I’m getting in my Imageless Glare study, so I decided to model a floor up in the air and make the occupancy schedule only during low sun hours. I’m still getting 100% of test points and directions passing a glare threshold of 95% of the time.
That sounds like staring at the sun the 3 hours of lowest sun causes no glare and I’m very confused.
The only thing I can think of is since it’s sustained exposure to the sun, it’s not a light/dark situation because it’s missing anything dark.
Anyone have an idea?
Hi @JimMarsh ,
How low of a sun angle are you using for your schedule and what direction do you have the sensors pointing? Are you using the HB Radial Sensor Grid component as is recommended for Imageless Annual Glare?
The results you are describing are not necessarily out of the ordinary but we would need more information to be of help. And remember that you can always compare your results from the recipe with a more detailed point-in-time view-based study like what you see in this sample if you want to get a better sense of what’s really going on at a particular hour.
@mikkel is the author of the Imageless Annual Glare recipe and he can likely answer any technical questions you have about it. And @Nathaniel is sometimes able to check the forum and he’s the person who originally developed and published the Imageless Annual Glare method, which he describes in detail here on his Github.
1 Like
Here is an image of the Sun Altitudes, Dates of Solar Exposure, and Schedule setup.
The HB_Apply_Room_Schedule is plugged into rooms_ on HB Model.
- Sun angles look to be 6, 14, and 20 during the selected occupancy schedule.
- I’m using HB Radial Sensor grid with 6 directions.
- Thanks for the point-in-time recipe, I was looking at an older one on Hydra and haven’t done that Study in LB Tools yet, only Legacy.
- I read that Github (sort of), but it’s a little over my head in some parts.
It just feels like 99.62% is way high for a lower bounds. On this next floor plan image I sketched where there are roughly 2 story tall curtain walls in the HB model. The coloring actually makes some sense because the higher numbers are looking away from the sun, but mostly the bounds of the analysis values is giving me a red flag vibe.
Edit: For my next post, notice the two random dots on the plan because that is where the fisheye was taken on the first level.
Here are the point in time studies. I forgot to plug in the correct date for the legend, so ignore that, but they are Dec 21 7AM to 9AM.
At 8AM-9AM the glare is intolerable, so I would expect the legend from the grid-based study to have a lower bounds of around 33% for the vectors looking straight towards the sun.
Hey @JimMarsh ,
I see what’s going on. You’re assigning an occupancy schedule for energy simulation (using the HB-Energy components), which as no effect on Radiance simulation or the occupancy schedule used to compute glare autonomy. Radiance properties and Energy properties are completely separate in Honeybee.
To change the schedule used to compute glare autonomy, you need to use the HB Annual Glare Metrics component and you can plug that schedule you have created in for the _occ_sch_. Then, you will be computing Gare Autonomy with your custom schedule instead of the default one.
I still would not expect the lowest Glare Autonomy to be 33% since looking at some of the worst hours of the year in your point-in-time study isn’t going to match up with looking at 7:30 to 10:30 every day of the year like your Fixed Interval schedule there. But the results will probably be closer to what you expect.
That makes sense. The only problem is I was trying that earlier, like the following image, and I can’t get past the error code.
- Solution exception:
The recipe failed to run with the following error(s):2023-06-30 14:47:08 ERROR: “DaylightGlareAutonomy” failed. See below for more information:
IndexError: list index out of rangeExecution Summary
Scheduled 29 tasks of which:
- 23 ran successfully:
- 1 AnnualImagelessGlare(…)
- 2 AnnualImagelessGlareLoop(…)
- 1 CopyGridInfo(…)
- 1 CopySunUpHours(…)
- 1 CreateOctree(…)
…- 1 failed:
- 1 DaylightGlareAutonomy(…)
- 5 were left pending, among these:
- 1 were missing external dependencies:
- 1 PostprocessImagelessAnnualGlare(…)
- 1 had failed dependencies:
- 1 _ImagelessAnnualGlarePostprocess_abf29326Orchestrator(…)
- 2 had missing dependencies:
- 1 LetImagelessAnnualGlareFly(…)
- 1 _Main_abf29326Orchestrator(…)
- 1 was not granted run permission by the scheduler:
- 1 PostprocessImagelessAnnualGlare(…)
This progress looks
because there were failed tasks
If I follow your directions exactly, the HB Imageless Annual Glare component finishes, but HB Annual Glare Metrics has this error that sounds like a list issue:
- Solution exception:index out of range: 8503
This is the data from the schedule object:
ScheduleFixedInterval: FixedIntervalSchedule_68be4ef3 [21 Dec - 21 Dec] [timestep: 1]
I also wanted to make sure 0.01 ft is okay for the sensor point offset. Should I be using something like 4.5 ft instead?
I may have figured it out. I used HB Schedule to Data before plugging into HB Annual Glare Metrics’s occ_sch (which I hope is okay) and now I’m getting something that makes much more sense to me. This is the floor plan for the 3 hours in the fisheye images above.
2 Likes
Glad that you figured it out and that is the correct way to do it when inputting the occupancy schedule to the recipe. Directly plugging in the energy schedule is only acceptable when using the HB Annual Glare Metrics component to post-process the results.
2 Likes
- I’m used to grid-based analysis grid offsetting from the surface by 0.01 units, but do I need to set the sensors to a height that’s closer to human eye level in this type of glare study?
- As I started spreading out my Analysis Period, at some point it freaks out and everything goes to 100%.
For example:
Dec 21 (7AM-5PM) works.
Dec 21-25 (7AM-5PM) works.
Dec 20-25 (7AM-5PM) everything defaults to 100%.
Ah sorry, due to previous setup for shadow study, I did not have the sky input coordinated with this annual study and I don’t think the sky had the ability to calculate before Dec 21 with the parameters I had set. I think my results are correct now for any time period.
1 Like