Greetings and thank you for your assistance. The issue I’ve encountered, as depicted in the attached image, pertains to the limitation of boolean union functionality beyond a certain number of breps. I’ve searched for a solution without success. I’m eager to hear any insights or suggestions. Thank you very much for your help.
simple Boolean union empty.gh (6.5 MB)
I doubt the number of breps has much to do with it. More likely the nature of the intersections, co-planar and curved surfaces, perhaps sequence of breps*(?)*, etc.
P.S. This top view shows that there are some duplicates and that most don’t touch each other. Sets of four (plus duplicates) touch each other.
There are things I could try… 
I wandered around for awhile, lost in the woods, though did find two subsets where SUnion did not fail. However, I finally took a different course and while this isn’t complete yet, it’s enough to file a report before taking a break.
Boolean union_2024Jan10a.gh (6.6 MB)
The ‘Tree/List Viewer’ and panel on the right are debug / trace features that can be ignored. The purple group at the top left (‘cull duplicates’) eliminates duplicate breps.
The Clash component is where the fun starts. It causes the connected List Item to generate a tree of one, two or three breps per branch. The Larger component finds branches that have more than one brep, causing Dispatch and Branch to build two separate data trees, one (A) with two or three breps in each branch and the other (B) with only one brep per branch,
All the single breps in ‘B’ are white and don’t intersect any other breps.
The ‘A’ tree tries to SUnion each branch, combining 2 or 3 breps into one, but as the panel shows (when connected to the SUnion output), it sometimes fails with ‘Invalid Brep’ or two breps or none. This is likely due to coplanar faces as mentioned before. So I tried MUnion (Mesh Union) instead but didn’t get the result I wanted until I added MJoin. These results are shown as multicolored shapes consisting of two or three of the original breps. In some cases, there are duplicates again. 
Ideally, one more “pass” would join the sets of 4 or 5 intersecting breps into single solids, all the same color, but I didn’t go that far. Careful inspection of top view shows how complex these patterns of intersecting arch shapes can be, as many don’t touch each other, No wonder SUnion failed 
1 Like
Well, I don’t really know what I’m doing with meshes but this looks correct to me. Would be nice to replace the two MJoin components (yellow groups) with SUnion - if they didn’t fail.
I added the white group to join the earlier bits, which results in duplicates that are culled,
Boolean union_2024Jan10b.gh (6.6 MB)
Warning, this gets into the weeds, I did some reverse engineering (orange group) by creating bounding boxes around the meshes derived earlier. Had to rotate the plane 26.124 degrees to get the boxes to align with the “grid” of breps. Then used BrepInc (Point In Brep) to get a data tree with each branch having all the breps for one box. You can see that worked by the colors from ColorBa.
SUnion should merge each branch of breps into a single “Closed Brep” but it fails as before. There are only two to seven breps in each branch so quantity isn’t the problem. It’s long been known that “coplanar faces”, including curved surfaces, are why it fails.
Boolean union_2024Jan10c.gh (6.7 MB)