Daylight analysis crashes for non-planar child surfaces.

[mostaphaRoudsari]

http://www.grasshopper3d.com/group/ladybug/forum/topics/rundaylightanalysis-radnonplanarchildsurface-issue?page=1&commentId=2985220%3AComment%3A1698351&x=1#2985220Comment1698351

[ayezioro]

Hi Mostapha,
I put an example with different cases as you asked in the discussion. This is the link:
https://www.dropbox.com/s/n9u0ru21nolg9ll/CurvedWall%2BWIndow_01%2BUniformTestPoints_Cases.gh?dl=0

All of the cases runs but case 1 (windows in two curved walls), which complains about the truncated octree.
Take into account that i changed HB_HB according to @AntonelloDN sugestion!!!
Thanks,
-A.

[mostaphaRoudsari]

Thanks Abraham. I'm checking the file now.

It's most probably the result of this change made by @chriswmackey. It seems what Chris has done makes sense. Maybe @AntonelloDN's solution covers all the cases and should be used. I'll report back.

[AntonelloDN]

thanks @ayezioro for the example file!

@mostaphaRoudsari I have noted that the case 1 doesn't work because the function "RADNonPlanarChildSurface" is executed twice (one for each curved surface).

[mostaphaRoudsari]

Hi @AntonelloDN, Thanks for your input. There is a minor fix to Abraham's example. The child surfaces should not touch the edges of the parent surface but other than that if we revert back to the original code before the change that I mentioned only case 1 is going to fail. Your fix, assuming Abraham has already implemented it in the file, introduced a new bug which was writing the child surfaces multiple time. You can use importRad component to import the radiance geometry to see what I mean. I'll work on case two today and will try to get it fixed.

[mostaphaRoudsari]

One more issue with the example file in case 1 was the srfName which should have been changed to a list:

Now all the cases are working fine.

I'll push a fixed version of honeybee_honeybee component to GitHub and will close this afterwards.

[ayezioro]

Thanks a lot Mostapha.
Sorry that i missed this "Multiline" setting in the panel.
-A.

[mostaphaRoudsari]

Thank you for finding the bug and sharing the example file! :)

[chriswmackey]

@mostaphaRoudsari ,

I can confirm that your change to the code that closed this issue has brought back the bug that was previously fixed by my edit. Now, I can no longer assign multiple RadMaterials to the different windows:
https://www.dropbox.com/s/ptchqd4ryq7pbfp/DaylightBugImage.JPG?dl=0

Note how the HBSrfs have the material assigned to them but only one of the window RadMaterials makes it into the final rad file. Here's an example that recreates the issue:
https://www.dropbox.com/s/g9gdykyo429x6k9/DaylightBug.gh?dl=0

The error results specifically because of the change that you made on this line, @mostaphaRoudsari
6a88cfe#diff-c2ecdd14851cd387b1d939828dbec897R2444

Since you are the one with the most knowledge of the Daylight workflow @mostaphaRoudsari , it might be best if you fix the issue. Otherwise, I will edit this line to use a try / except loop (using first the glzCount and then the [0]).

-Chris

[chriswmackey]

I just wanted to add that this issue persisted until today and so added a try/except loop:
c1eab3b
So this kinda solved both issues but it will not be correct when someone applies two different window materials to two curved child surfaces of the same zone. So it's still kinda a bug but it seems like such a rare case and, by everyone's silence on the issue, no one really has the motivation to address it. So I'm closing the issue and we'll just focus on HB+.