Model Groups - advice / guidance on approach

Revit
1

Hi everyone,

How are you managing attached Detail and Model Groups? It is easy to say “do not use model groups” or ,“you need to be more selective”, however, the use of model groups is a widely adopted method, especially at my practice. I was surprised to find that the API does not support this action.

Having scanned through the forum for a solution I feel like I’ve hit the proverbial brick wall. Having tested the process, I even managed to convince myself I found a solution.

This could be my lack of understanding, however, I feel very restricted. It is not possible to use dynamo for any element inside the Model Group (instance - greyed out). Therefore, I can not change wall - top constraint, height, offset, room - centering, tag centering… the list goes on.

I’ve seen forum posts discussing ungroups / re-grouping and then replacing the name. However, this seems very complicated and is not a fool proof solution.

Therefore, I’m looking for advice. How are you managing this process?

Although I’m relatively new to Dynamo, I’m starting to feel that sour taste in my mouth when I need to repeat the same task manually over and over again.

Any guidance / support on this topic would be much appreciated!

2

As far as I know there are two functional options, both of which you hit on:

  1. Don’t plan on using the combination of API alterations and groups, forcing you to select between two tools design to increase efficiency - either the API (add-ins, Python, Dynamo) or groups. No one likes this but that’s the API’s limit.
  2. Deal with the ungroup and regroup mess. Yes it’s complicated but it works with some caveats around element history.

Personally I like option 1, but I do most (all?) of my work via the API rather than the UI so I don’t benefit from groups but am hamstrung by lack of API access.

3

Hi Jacob, thank you for replying, it really helps to clarify my own understanding.

Using the API means that you enforce a standard in which you can control? Therefore, from the initial setup you are not limited by users “model grouping” unnecessarily? Whereas i’m jumping around on different projects and need to battle with different knowledge levels and the pure conviction from some that model groups are the only way for everything.

Option 2 - the element history is my concern for external model coordination, nevertheless maybe this is an option I need to explore in more detail.

Thank you.

4

Most of my work isn’t directly collaborating with other Revit users. The last time I had to sync a Revit model so other users could access my changes was ~5 years ago now. I have to synch GitHub now instead. So for me I can do what is best for me, but if you’re collaborating you need to work with those users.

If you’re building tools to automate all the things, then groups are not as necessary. if you’re building some tools to automate some things then they likely need groups. I am going to go out on a limb and guess that you aren’t automating ALL the things which groups were doing for users before, and therefore you’ve got to allow some degree of grouping is required.

If the users are convinced and can demonstrate that there are no disadvantages for model groups, then you either need to work on some change management or you need to limit your automation to things which are not grouped.

5

Yeh exactly, I’m the only Dynamo user and my knowledge is pretty basic to put it politely. Therefore, convincing users to move away from Model Groups or reducing their use will certainly be a challange.

Again, thank you for your response, it has provided me with some resolution in my own mind. I can only hope that Model Groups become more responsive within the API (Christmas wishlist).

6

My two cents:

  • There’s plenty of stuff to automate that isn‘t affected by groups so I wouldn’t make automation the reason why groups should not be used (there are plenty enough other reasons for and against them for sure). But if you offer a wide range of scripts at your firm it makes sense to educate users which of them are group-compatible and which aren’t and then let them do the maths wich modeling approach will save/cost them more time.
  • Any scripts that will have issues with grouped elements should filter out those elements as early on as possible and at the end of the script report those omitted elements to the user (we typically export an excel list) so they know what they‘ll need to fix manually.
  • Project parameters of type text and similar can be configured to be set via API within groups - that also covers a lot of automation scenarios.
  • Evaluating groups with Dynamo is fairly easy and most of the best practices around groups can be checked with little to no effort - another use case (which can supplement proper training about groups).
2 Likes
7

Thank you for the advice Andreas,

very useful, some great tips!

it’s given me something to think about, especially your 3rd point, project parameters to groups.