Revit Model Groups are a wonderful thing. They allow capturing repetition in the building model, and provide a way to tag through the groups, maintaining unique instance properties of the contained elements for scheduling. Determining best practices for Revit Model Groups has been challenging and a moving target. Some old rules no longer apply. I love the fact that The Factory has been making strides in improving group functionality and stability from release to release. For instance, mirroring works very reliably in Revit today, versus 2 years ago it was verboten. Here are my first two good rules to begin with that are hard and fast (until some new feature makes them obsolete one day), and they are:
- Constraints on elements will bust the group, whenever the conditions of the constraints change. My best example of this is: You cannot have walls with level-attached tops inside a group if any floors you wish to place those groups on another level that has a different floor to floor height.
- Instances of Groups must be composed of identical elements. Like an AutoCAD block, if you remove an element from one, it is no longer contained in any other instances of that group. (R.I.P. April 15, 2008, with the ability to Exclude elements from an instance of a group – Hooray!) But, there’s a catch. Beware of hosted elements.
For this article, let’s focus on Rule #1.
The sneaky thing is: You may observe the behavior for walls inside groups is benign. As you may know, elements such as a wall can be given either an explicit height, or have its upper extent constrained to a level, floor or roof element, or a reference plane. Since nested elements must remain consistent in every instance of a group, those which contain walls that are top-constrained to a level, attempt to respect the resultant height of the constraint to the next adjacent level. At least the walls do not break the group if placed on levels whose floor-to-floor height varies. An override for Top extension is auto-magically placed on the new nested wall instances to keep them consistent, and no warnings are displayed. You have to be mindful of what really happened. A properties override, if you will, was assigned to the new walls during their creation. Looking at the walls from an section or elevation may not show any difference. The original constraints are still present so… can we do it?
Not So Fast! Remember this: If you attempt to change the height of your levels, you will be in a severe amount of pain. The feared warning will come up stating: “Group instances of the same type do not contain identical members.” When you are presented with the option to Fix Groups… Revit simply asks you to ungroup or make unique groups for the naughty thing we just did. Rule number 2 still applies.
Recommendation: Be cautious
So, it might be best to create groups for large room-based compositions which include walls to be designated by the level the were created for. New groups should be created for the other levels, and so on… You should ask yourself whether the walls are helping or hurting you if inside a group. I’m not saying you shouldn’t, but you should consider the consequences. Because of all this chicanery, I still recommend for cases such as demising walls, or any other conditions where walls are to be stacked one on top of the other, don’t model these per floor, and certainly don’t place them in groups. You may be better served to model them with a single-spanning wall starting on the lowest level and connected to its uppermost limit. This is easier to make changes, and accomplishes an efficiency with less geometry in the model. Think shaft walls, plumbing chases, and tenant separation walls, as these are critical to be sure they actually stack. Unless you are building a construct-ability model, don’t build it the way it will be constructed in reality, but to convey design intent. Structural engineers and contractors will probably argue with me on this one, but at least in the early stages of design, it is a far easier thing to manage the building model this way.
Got any best practices of your own that you wish to share? Feel free to add comments, or drop me a note from the contact me page.
I can’t believe you guys accept these kind of bugs in a software package! Groups and blocks are supposed to be part of any modern CAD package, not some wonderful extra feature or add-on. Revit is being touted as the best software out there and only recently could you successfully mirror groups?! And changing the level of a group causes problems when drawing in Revit is based on levels?!
We don’t accept it, but I have since learned to live with the fact that all software has shortcomings. For all that Revit excels at so thoroughly well, since there are many ways to represent repetition, including families, links, and others, it ain’t so bad.
Having constrain-based, parametric modeling, which also allows sustainable design analysis makes me happy. The ability to simultaneously have multiple designers work on a single file across the WAN on both ends on the country or the opposite side of the world in real time makes the firm happy.
I am working on a multiresidential townhouse project that is built on a slope. I have my unit types as groups defined off to the right of the site. I am having no end of grief with placing the groups at the proper rotation and elevation without them fixing themselves, uniquing themselves or deleting themselves. Some groups refuse to be copied, one refused to rotate 180 degrees but let me mirror it twice for the same result. The thing is I would like my groups to not try and heal themselves at each transform until they are in their proper place. For my next project I am trying to make each unit as a separate project linked into each building as a separate project linked into the site plan. Grandfather, father, child. It looks promising. But I am hoping I can fix these groups in this project so I don’t have to redraw them.
Do you have any suggestions on creating a three storey group that does not mind being raised and lowered to other levels?
Groups are so touchy. This I will agree. When their contents are complex, and contain many interrelationships with each other, they don’t always behave as expected. For instance, rotating or mirroring a group that contains a gridded ceiling gets very confused. What I have begun to tell designers is that the preference for repeatable elements in the model are: Family, Linked Model, then Group. I will be exploring the Assembly feature in Revit Architecture 2012 to see if there is a new opportunity to rethink this.
So since your collections of repeating elements contain walls, linked Revit models would be your best approach. Thankfully, The Factory gave us the ability to save a group as a RVT file, which can then be linked in. When projects become very large, the other advantage of this approach is you can document and create sheets for the units as a standalone file. You can also manage how much detail is brought into the main project, by placing those things you do not need to see in the assembled building into their own worksets, and choose not to include those worksets when linking.
This approach goes back to the way we did unit plans back in AutoCAD, and later ADT at the first firm I worked almost 15 years ago in the little city of Newburyport, Massachusetts. Check it out if your ever travelling. It’s a great little New England town. Stop in to EGA Architects, and tell them I said hey!
Thanks for the reply. The second townhouse project has units linked into buildings which are linked into the site. It seems to be behaving very well except that my site plan is littered with refrigerators, closet shelves, and vanity counters from all the floors. It seems these don’t like to behave with the change in height (up 83 ft.). I will take your advice and place these into their own workset at the unit level so I can turn them off on the site plan. Otherwise, this is definitely the way to do these townhouse projects.
I started AutoCAD when they just added the DIM command for dimensions and they still had only the 7 named colors. I was on AutoDesk Architecture when it was still Softdesk version 7. The last place I worked at, they used an AutoCAD / Sketchup combination for all their drawings and it worked fine. Now this place I am at is a Revit only shop and I have to get used to the amount of control Revit has over the database. I am still finding my way!
Since you guys are talking groups and links (or were a while back). We are having a couple of issues. Maybe you can provide insight.
1. Links: We link units into a building and then the building into the site. The site file has become impossibly difficult to deal with. We have about 20 unit types and around 450 instances of those 20 types. Is it normal to have this much difficulty with a double linked file? Our site file crashes often and is very slow. There is definiltey something wrong and I am troubleshooting as best I can.
2. Groups: We have one floor of the building that seems to “ungroup” the groups that are placed on that floor. The groups are still identified as groups when you try to change a wall or element but each individual element looks detached from the group. You don’t get the normal group box when hovering over the group. You still get the box in a 3D view but not in plan. Any thoughts?
Thanks.
Ok – I’m sitting here and had this crazy idea to recreate that particular floor.
Suddenly, the groups act likes groups. Blue box, highlight all elements at once, etc.
Revit!? – can’t explain that one.
1) Regarding the multiple links, using a container file to bring them into the site makes sense, however, unless you are using shared coordinates, that behavior is difficult to investigate.
I would expect that you may need to recreate one of the central files, or at least open them up individually with Audit enabled.
2) It’s possible that the view was corrupt, and that was why it was displaying differently in 3D versus plan.
One situation I have come across frequently is elements such as furniture become hosted to a floor, versus associated with the level datum. This can happen even when families that are not designed to be hosted are placed – very unpredictable.
When the floor face is hosting members of a group, it becomes very difficult to place the group on a different level, as those elements belonging within the new group instance become “sticky” to the original floor. The only way around this is to ensure the floor category is not visible while placing the original elements you intend to group, or place them off to the side, outside the building and then move into position.