Revit Groups - They Broke
- bimtheworld
- Nov 7, 2014
- 3 min read
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. 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.
Original article found here:
Commenti