Hello all,
Is there a better way to get the top most Parent Group an element lives in? I am not sure on the depth of Groups inside of Groups inside of Groups… The method I show her works but I feel may be processor heaver on large projects. This Method is also stopped at 7 tears and while I do not think someone will model groups this deep, I have seen stranger things in Revit.
As I was posting this I did think of this method which solves my problem in a different way. My original end goal was to find a collection of elements top most group but I guess I can just grab all the groups and see which ones are at the top. I am wondering if there is a way execute my first method though.
Nested groups are bad… like real bad… like don’t ever do it level of bad.
But since you asked and clearly have a need: I think you would have to write an iterative function for the other direction on this. If you provide a sample file I can look into it, perhaps this weekend.
I was not aware that nested groups were this bad. Is it bad from Revit’s end? like it causes corruption and crashing? Or does it just prevent users from saving work done in nested groups when someone comes into the parent group after them (Comment #6 First Link)?
Thanks for the offer @jacob.small it was more of a curiosity things than a need at this point and I don’t want you spending your weekend working on it.
Some quick Googleing to find out more.
https://www.revitforum.org/architecture-general-revit-questions/15792-groups-within-groups-nesting-groups.html
Well, they are better than they used to be, but the issue with constraints and references between groups still causes enough issues that I recommend everyone stay clear of them still. That said I haven’t tried 2018 or 2019 to check for the typical breaks and bugs. I guess they could be fine if you are fine with losing the parameteic benefits of all elements in the groups, which really you’re giving up by having a group in the first place so… have at it I guess.
Mirroring is better than t used to be as well (though I think sketch based elements still suffer some issues occasionally).
So, that’s why I say ‘don’t group in groups’ as a rule of thumb.
Don’t be surprised if I have a solution next week for the other method of tracing these. The issue is too interesting for me to avoid. 
We have had some seriously complicated model grouping arrangements in our office (somewhat recently) and yes it has caused editing / update and reproduction headaches, cue revit-the-toddler…
revit “a new group will be created!”
me “why, revit?”
revit “because”
me “no, seriously why revit?”
revit “because i say so”
me “can you give me a reason?”
revit sticks its fingers in its ears and does it anyway…
(You might recall a lengthy discussion on changing group parameters I had a while ago… but I’m not bias, honest… 
I did educate the user around creating project specific families and having an external revit file for the “grouped” elements, linked multiple times into a project (functions the same so why not) 
Well if you really want to work on it then I am not going to stop you. I built a quick sample file to get you started. Again no need if you are busy.
Groups.rvt (1.3 MB)
Groups.dyn (20.4 KB)
I know my office is building all non-hosted families to be used in groups. Personally I think that sounds like a pain but needed if you are going down this route. Not sure how the groups are going to be handled just want to make sure I am ready for whatever people through at me on this new project. I hate when people use nested groups they just all out suck to work with.
@Ewan_Opie Thanks for the reply, the link, and the laugh. I have thought about Revit as a toddler many times when it comes to groups. I have had this happen when I edited a group and checked a yes/no parameter (nothing else). All groups should update with the change but Revit says otherwise.
Thanks for the info and the help,
Steven
You could modify the code in Element.Group to be a recursive function like so:
import clr
clr.AddReference('RevitAPI')
from Autodesk.Revit.DB import *
clr.AddReference("RevitNodes")
import Revit
clr.ImportExtensions(Revit.Elements)
elements = UnwrapElement(IN[0])
elementlist = list()
def parentGroup(item):
if item.Document.GetElement(item.GroupId) == None:
elementlist.append(item)
else:
parentGroup(item.Document.GetElement(item.GroupId))
for elem in elements:
parentGroup(elem)
OUT = elementlist
This way (verse your other method of collecting groups) would maintain list structure to get the top parent group of each respective element. If you eliminated the portion that removes elements that aren’t in groups, the script will just return the non-grouped element
PS I’m only sharing this as an example of making the script recursive, I do not condone nesting nested groups 
Thanks Amy,
A recursive script is much simpler than I figured it would be. Very helpful to see how its done.
Sorry she took all your weekend fun @jacob.small.
