Hi forum,
I’m struggling with stripy lines appearing in the results of my annual daylight simulation. The model is within 200m of the origin, the issue is happening for both detail level 0 and 1 (I haven’t tested 2 yet). The image below is previewing the DA result.
This is part of a parametric simulation, and I have a variation of the model with slightly different floor plate and sensor grids that doesn’t produce this issue.
Each surface is its own sensor grid, and when I use grid filter to select a subset of the rooms their results look good to my eye.
I’m sure this is just a shortcoming of my limited Radiance knowledge. I’ve had a similar issue in the past with DF simulations, but using the AR input solved those. From what I can tell the annual daylight sim doesn’t take AR as an input.
All grids
Using grid filter
@mikkel please would you be able to take a look? I’ll send you a DM with the HBJSON and epw file I’m using.
For anyone joining the CIBSE Daylight Group call this Thursday this is a sneak peak at what I’m presenting on.
Some additional information, I’m also running daylight factor and annual irradiance on this model. Daylight factor returns “normal” looking results, but annual irradiance gives the same stripy pattern
Further info, something seems to have gone wrong with the results structuring.
The model input to the AnnualDaylight and GetGridsViews is the same, but the result structure output from AnnualDaylight doesn’t match up with the input sensor grids (as far as I can tell).
I’m still looking into this, hopefully a useful update
Hey @mikkel, I think one of my colleagues has spotted my error. I’ve accidentally got two sensor grids with the same name. This seems to account for the mismatch in result length and mesh size.
I’ll make a change and share if this fixes the problem
That’s fixed the problem, sorry for the inconvenience!
Thanks to @mgillot
2 Likes
Hi @charlie.brooker - I have randomly got the same error; though as far as i am aware i haven’t set up sensor grid names manually. The HB Sensor Grids from Room component is just taking the name of the room as the sensor grid name.
What was your fix in the end? any ideas on what else could cause a mismatch?
Splitting up the floors and running independently, i can narrow down which zones are erroring (it’s a large building model with 250 rooms).
Any help appreciated!
Thanks,
Leighton
Hi @LeightonSS55,
There’s a couple of reasons I can think of - one would be a mismatch between results and meshes, the other is that the model set up / radiance parameters are causing the issue.
If your model is a long way from the origin that can mess with results, but if I remember correctly that’s more limited to daylight factor than annual daylight.
I’ll do a quick test now to see if I can replicate on something smaller - out of interest do you define room names earlier? Or are you letting HB automatically name them?
Cheers,
Charlie
Another check would be model units - are you working in meters? That could also be throwing Radiance off
I’ve had a go at trying to replicate the issue but without success.
The main thing that jumps out at me as could potentially cause a problem is the way HB handles grid naming, it doesn’t pick up any kind of unique identifier and relies on the room name only - @mikkel potentially a mostly unneeded change, but perhaps the ID of the room could be inherited to avoid any risks around grid referencing?
Amazing thanks for getting back!
Origin is dead centre and meters are unit of choice.
I haven’t defined the names just due to the size of the model & the stage where you need create rooms & solve adjacencies has always bloated the script. Happy to see if there is better practice in this regard - no doubt it will involve data trees.
I’ve tested all floors and apart from the top floor, and they are producing reliable results. A previous simulation of the whole building last week didn’t cause this issue - come to think of it, when simulating the whole building, the error in the top floor ‘infects’ the resutls of the whole building - which leads me to think its a mismatch mesh issue - not sure on the solution though!
What’s the best way to internalise the data/send the model & GH script over to you?
thanks!
Sounds like you’ve set the model up in a way that’s least likely to result in any problems - happy to have a quick look at the script / model, can’t promise I’ll be able to fix it, I’ll send you a private message with my email address so you can share however best suits you.
There’s a slim chance this script might read and apply results correctly - worth giving it a try.
Load daylight results from folder.gh (21.0 KB)
Thanks for sharing and the offer - Legend.
I’ll give it a crack and maybe try refresh connections in the script for 5th floor - just in case its a bug in the physical geometry before i share - in case it’s something simple like that.
1 Like