Groups v. Links - Multi-Family Residential

[Devin_82]

A few of the AU Unplugged sessions dealt at least in part with this topic and I was hoping for a little continuation. My company mostly works on Type 3 and Type 5 podium apartment projects in southern California. If anyone is working on similar building typology, would you mind sharing your thoughts on this topic? I have seen a few posts on this, but they haven’t been visited in a while…

How are you dealing with repetitive unit plans that invariably have some slight changes on the skin (i.e. shifting windows, small pop-outs, small recesses, etc.)? The same internal guts of the unit are used in many different locations on different elevation styles throughout the building. Groups have some advantages to them like excluding walls for special cases and more flexibility and succinctness with schedules. There was some discussion of using linked files instead of groups and I was hoping to get a feel for some of the pros and cons of both as experienced by people working on similar building types.

As an aside, it seems to me the idea of Building Information Modeling would lend itself more to the single file, single model, grouped methodology rather than the multi-file linked methodology. I know most of us are still a ways from true BIM, but I want to try to keep an eye toward the future and stay optimistic that it is coming sooner rather than later.

[Scott Womack]

A few of the AU Unplugged sessions dealt at least in part with this topic …

How are you dealing with repetitive unit plans that invariably have some slight changes on the skin (i.e. shifting windows, small pop-outs, small recesses, etc.)? The same internal guts of the unit are used in many different locations on different elevation styles throughout the building. Groups have some advantages to them like excluding walls for special cases and more flexibility and succinctness with schedules. There was some discussion of using linked files instead of groups and I was hoping to get a feel for some of the pros and cons of both as experienced by people working on similar building types.

As the moderator for this session, I guess I'll give a recap. There was a spirited discussion on both approaches to this issue. Some prefer Links while others prefer groups. Several firms represented actually use a combination of the two. Some link the units into a floor then group the floor, others group the units into a single floor, then link the multiple floors into a final building. Nearly all kept the exterior walls in the main file, and had them continuous for the building height. One approach also used a grouped or linked unit with all walls that stack running continuous top to bottom of the building.

Short answer, is that currently there is no consensus on the issue. It depends upon the issues surrounding each project.

Personally, we have been having success with using linked units until the floor plans have been largely stabilized, then we are binding the links and turning them into groups for the construction documentation. Several of the others there will have strong opinions that may run contrary to our story, for equally compelling reasons.

[twiceroadsfool]

<----- Really enjoyed all the discussions. :)

I use groups for the individual units, and links for each floor. Skin in the main file, OR in another link by itself, depending on complexity...

[ghale]

I'm glad a new thread was started on this topic. I'd like to see if we could go into a little more detail with the idea of groups, links, and best practices. Getting these best practices in order will help the Revit community take great strides with larger projects and avoiding many of the pitfalls each of us has run into. I understand that this methodology largely depends on project and file size, but the same practices will make the process more efficient no matter the project size. It will also help with consistently approaching projects, then adjusting to the situation.

I think that most of us agreed that units are best handled in groups and the exterior shell can remain ungrouped extending multiple floors. The question to me then becomes, what gets included in the unit groups or links?

1) Do you include the demising wall between units or exclude from the group as necessary?
2) Is furniture included in the unit group, as a nested group, or a nested family?
- Should all hosted elements be unhosted? How do you go about this?
3) Are ceilings and rooms typically included in groups? I do not include them.
4) Do groups need to be duplicated for mirrored units or rotated units? I have found trouble with both mirrored and rotated units if they contain hosted elements. I've heard that unhosting solves this.
5) Do you need a seperate unit type for different floor to floor heights?
6) Once these groups are set up, do you group the entire level including the floor, save off, and link back in as additional floors, or do you simply place the groups throughout? I imagine this is the critical piece to breaking up the project, and depends largely on project size. Simplicity is the key. I would only start linking once the file size became too prohibitive. I also typically group the floor(physical floor not including units) on each level, then place at each level.
7) Are your unit groups always saved off as external files and reloaded into the project as changes are made? I try to keep the groups in the project without saving externally, again for simplicity sake.

As you all know, the more workarounds you have, the more difficult the project becomes to manage and the less likely you are to get buy-in from the project team. Let's keep it simple and intuitive. Thanks

[Scott Womack]

I understand that this methodology largely depends on project and file size, but the same practices will make the process more efficient no matter the project size. It will also help with consistently approaching projects, then adjusting to the situation.
1) Do you include the demising wall between units or exclude from the group as necessary?

I can only give my personal take on the issue. There were several at the session that strongly thought links were the only way to go. I use linked units until the floor plate/shape settles down. Then I bind the links, and turn them into groups. This avoids much more of the possibility of a group becoming corrupted.

Personally I do, although it depends upon which way the structure is running, from exterior to corridor, or from shear wall to shear wall (demising walls). This fact alone will dtermine what is in the group and what is not.


2) Is furniture included in the unit group, as a nested group, or a nested family?
- Should all hosted elements be unhosted? How do you go about this?

Yes furniture is usually in the group. I usually use hosted objects on those walls that are in the group. Un hosted when they are against walls that are not in the group. To create un-hosted families, yo need to re-create the family a second time.


3) Are ceilings and rooms typically included in groups? I do not include them.

I do place ceilings in the groups (College dorms) This provides some consistency in what are hard ceilings and what is not.


4) Do groups need to be duplicated for mirrored units or rotated units? I have found trouble with both mirrored and rotated units if they contain hosted elements. I've heard that unhosting solves this.

It depends upon what is hosting the object. I never use floor hosted objects. I try to avoid objects placed by the 2 point creation methods.


5) Do you need a seperate unit type for different floor to floor heights?

I use walls that are not attached to the level above, to avoid issues copying from floor to floor levels.


6) Once these groups are set up, do you group the entire level including the floor, save off, and link back in as additional floors, or do you simply place the groups throughout? I imagine this is the critical piece to breaking up the project, and depends largely on project size. Simplicity is the key. I would only start linking once the file size became too prohibitive. I also typically group the floor(physical floor not including units) on each level, then place at each level.

There was absolutely no real consensus on process, except that it was project dependent. Several of the attendees stated that they might use different approaches, based upon the project constraints.


7) Are your unit groups always saved off as external files and reloaded into the project as changes are made? I try to keep the groups in the project without saving externally, again for simplicity sake.

For the most part I agree. We do save the groups (units) from a project once it is near CD completion, for potential reuse in future projects.

Good Luck!!

[twiceroadsfool]

Heres my abbreviated take, on using Groups for UNITS and Links for FLOORS.:


1) Do you include the demising wall between units or exclude from the group as necessary?

I leave the demise walls out of the groups, and have reference planes around the groups. If something needs to be hosted on that wall, you have to either watch it carefully or make it an unhosted family...


2) Is furniture included in the unit group, as a nested group, or a nested family?
- Should all hosted elements be unhosted? How do you go about this?

I keep them in the Unit "Group", but after the AU session, im rather curious to try them nested in a family, all shared... But TO DATE ive included them in the group. I dont use hosted elements on hosts that arent in the groups, but i tend to keep hosted and unhosted versions of my families, so its not an issue.


3) Are ceilings and rooms typically included in groups? The ceilings go with the unit groups, for me. That way lights and whatnot can go as well. With 2x4 ceilings it can be a pain with the surface pattern, so we sometimes end up having to remove the ceilings after we place the groups, but...

Rooms, i keep in the Linked Floors. On a project by project basis, ill evaluate if some of the *smaller* rooms can go in the groups (Suite bathroom, etc).



4) Do groups need to be duplicated for mirrored units or rotated units?

I prefer not to, but we sometimes have to when Line based and hosted stuff is a problem. We can unhost stuff, but we cant unworkplane a line based family, and we use a lot of them.


5) Do you need a seperate unit type for different floor to floor heights?

Since i use links, i do not. In the Linked FLOOR, i have a bottom and top level, and i constrain the walls. if there are different FTF heights, i use design options.



6) Once these groups are set up, do you group the entire level including the floor, save off, and link back in as additional floors, or do you simply place the groups throughout?

Since i use links for this already, i do not. I place the links on the different levels, name them accordingly, and use a View Template to manage any design option configurations i need for the different floors.


I also typically group the floor(physical floor not including units) on each level, then place at each level.

For me, this is project specific depending on what is "driving" the geometry. If its based on a complex skin, i obviously dont have the floors in the Links, and Floor hosted objects have to be unhosted. If its perfectly repeatable floor to floor, i have put the floors in the linked files before.



7) Are your unit groups always saved off as external files and reloaded into the project as changes are made?

I ALWAYS save ours out. Ive got the Linked Floors files next to the Main Model, and the Groups in another directory. That way, if the group needs to exist in more than one model, there is a system in place. Whomever is editing the group needs to edit the group definition, then make sure it gets repopulated in to the other files.

[dhurtubise]

Smaller projects, i sue groups. Larger one's linked files with Design Options.

[ghale]

---Quote---
2) Is furniture included in the unit group, as a nested group, or a nested family?
- Should all hosted elements be unhosted? How do you go about this?
---End Quote---
I keep them in the Unit "Group", but after the AU session, im rather curious to try them nested in a family, all shared... But TO DATE ive included them in the group. I dont use hosted elements on hosts that arent in the groups, but i tend to keep hosted and unhosted versions of my families, so its not an issue.

After AU, I'll have to try using nested families within groups to see if this fixes some issues. I hate to have to recreate many hosted familiies such as wall cabinets though.



---Quote---
4) Do groups need to be duplicated for mirrored units or rotated units?
---End Quote---
I prefer not to, but we sometimes have to when Line based and hosted stuff is a problem. We can unhost stuff, but we cant unworkplane a line based family, and we use a lot of them.

It looks like I'll have to duplicate some line based families as well, such as countertops, and make sure they are not used as line based families in these grouped units.

[twiceroadsfool]

Im not giving up my line based families, no way. I use them in a ton of places. id bail on groups before...... LOL.

[Devin_82]

I guess because of our project type I am having a difficult time seeing linked files for units and especially whole floors being the best way to go. I guess for units it could see it working, but im not sure what the advantage would be. I will definately be testing it out over the next couple days or so to see if I can figure it out.

As for linking whole floors, there are only typically 4-5 levels in our project types and there are different amenity spaces spread throughout the different floors and in different locations on those floors, so I don't think there is enough repitition to link and deal with the limitations in scheduling (though I know these have been improving lately) and the clean-up issues with the skin walls.

Right now we are using groups and excluding the exterior walls and any other walls that typically occur and only occasionally need to be changed. I have a few reservations about the excluding function. How, if at all, are you all using that particular function.

I have also had some issues with the mirroring of the unit groups. Some of my hosted stuff can flip out a bit.

[twiceroadsfool]

I did a project that was only 6 floors, and of the six there were 3 variations. I still used links, as it meant only having to build ONE floor. I used design options to encapsulate the differences, and the whole thing was built in an 8 hour day.

Im not sure about the limitations people are facing with schedules. If i have a room or door schedule, each Linked Instance will have "Room 1, Room 2, Room 3, etc". So i simply give the linked instance the name (or a number) of the floor, and put the "RVT Link: Name" field in the Schedule as the first column, from the catagory "RVT Links" and the schedule looks like

Floor 1 Room 1
Floor 1 Room 2
Floor 1 Room 3
Floor 2 Room 1
Floor 2 Room 2... And so on.

With formatting and headers, etc, i really cant see what the limitations would be, sans keynoting acrossed linked files. But to each their own.

As for excluding items in groups, i dont use that feature at all, and i restore any exluded elements that i come across having been excluded, in our projects. It stoo easy for it to be an off hand mistake, and too difficult to keep track of. Unless im the ONLY person on the job.

The benefits are plenty... Even with 5 variations of floors, i can work in the main model and not have to carry 4 of the five at any given time. And when i need to edit them, im in a model thats basically only 1 floor "heavy." It works great. :)


***EDIT: Worth mentioning, the first time i was asked to set one of these jobs up myself, i went about it the same way you guys are. Links for individual units, and groups for floors. (the opposite of what im saying now). I didnt try it my CURRENT method until someone here told me how much better it would be. Havent looked back since. :)

[Devin_82]

Looks like I have some messing around to do. One 8 hour day would be quite a time savings over the way things are working right now.

So, let's see if I got it. You have grouped units that make up one floor within one file. That file is then broken apart by design option for the floor by floor variations and linked into the "master file". Within the "master file" you have your exterior walls and everything else.

If I remember correctly from the Unplugged session, some people were also linking in a seperate file for the site?

[twiceroadsfool]

Thats the way of it. Get comfortable with View templates though, and here is why:

You need to use View templates in the main file to delineate that in EVERY view, each instance of the link is a particular design option. You ALSO need to apply that to the schedules...

Also, if there are 3 "steps" on a massive skyscraper, and those three are HUGELY different, then ill sometimes use 3 linked files, and make the minor variations within them as design options. But thats a project by project decisions, in my opinion.

[sbrown]

I'm not answereing your direct question because I still don't have a satisfactory answer to give. After spending many hours discussing this with everyone I could at AU, I'm still convinced that we need to press Autodesk on the issue. It shouldn't be a groups vs links discussion. It should be a "unit maker" with coarse, med. and fine detail levels or something like that. It should behave like a family, group and link. It should be able to have 2d symbol, schedule, join when join geometry is applied, be light weight to the model, etc.

What I came away with was that Groups are still a pain but "more revit like" Links are stable but "more autocad like" So if you like to manage layers(view visiblity) go with links, if you like to wrestle with geometry go with groups. But you won't be very happy with either (unless your Aaron who loves his links:)

[twiceroadsfool]

Im just a ball of sunshine!!! LOL....

[Scott Womack]

What I came away with was that Groups are still a pain but "more revit like" Links are stable but "more autocad like" So if you like to manage layers(view visiblity) go with links, if you like to wrestle with geometry go with groups. But you won't be very happy with either [/quote]

Well stated Scott. That is probably the clearest, most concise "summary" of what the discussion came to.

Take Care!

[ghale]

What I came away with was that Groups are still a pain but "more revit like" Links are stable but "more autocad like" So if you like to manage layers(view visiblity) go with links, if you like to wrestle with geometry go with groups. But you won't be very happy with either (unless your Aaron who loves his links:)

Well said Scott, but it sounds like you're running for office. :?: I'm hoping to get a few more opinions here, and then maybe summarize some of the pros and cons of links and groups with respect to units to steer us clear of major pitfalls. There are some good tips here so far.

[twiceroadsfool]

Scotts summary is perfect, but we can all take solace in the following:

While ive had trouble getting "convert to link" and "bind" to work properly, the beauty of the new functionality we got around 2008 or 2009 (dont remember) is that we can undo these decisions later. Groups can get turned in to links, links can be Bound back to groups, etc...

What we should have done was actually typed out the Pros and Cons list from Scotts Unplugged session. (Or did someone, and i just havent found it yet? If so, i apologize, i was *burned out* after last week, so i havent made the rounds of blogs yet...)

[sbrown]

I plan to put together a summary that is not "politcally correct". I'll post it here. Once I get to it.

[Devin_82]

I agree, a summary of that Unplugged session would be helpful to the conversation. You guys were in a groove and bounced around a lot of good ideas. I was content to absorb what I could. A good pro/con list would hopefully give people a chance to test the ideas out and maybe even solve a few of the cons, or poke some new holes worth mentioning in the pros. The more minds we can get focussed on this, the better. Maybe Autodesk will take a little notice of the amount of chatter and take on some of the responsibility for helping us users resolve these issues.

[sbrown]

Please add to this as you recall. Here is my list of Pros and con of Linking

Linking

Pros
Smaller Files
Team Role Separation
Consistency of Copies
Flexibility
More AutoCAD like, i.e. xrefs

Cons
Multiple files “Not Bim like”
Management issues
System names
Avoiding duplicates
Dealing with Documentation issues
Graphics
Visibility
Scheduling
Elevation Views

Grouping

Pros
Workflow
In Place Editing - Exist in Host File
Model Cleanup
Live view creation
Scheduling
Less Management
Overrides
Performance???
Can be converted to links to work on separately and reloaded.


Cons
Performance
Known Issues
Mirroring
In place Families
Heights by level
Inconsistency
User errors
Ungrouping errors/warnings

[Scott Womack]

Scott,

The only other item I have in my notes is a Pro for Groups:

The exist in the file. Your In-Place editing is much the same thing.

[Tyveka]

So has anyone actually gone back and tried the "groups as a family" experiment yet?
I'm curious as to how that works - how would you handle the walls in each unit, etc...? If anyone's done it yet, can you post here and let us know what to watch out for?

It sounds like it has potential but I'm still a bit skeptical...

[sbrown]

The discussion of groups as families has nothing to do with walls or system objects. Just nesting all the "stuff" in a unit. The way it works is as follows.

Export your unit plan to cad> Import Cad into GM family. > Load all non hosted families used in the unit into this GM family(note make sure you first change all the families to "shared" families). Arrange them all on top of your cad plan then delete the cad plan. Load family into project and copy / mirror as needed.

This works great for all casework, furniture, specialty equipment, etc. anything NON hosted in the unit.

[kreed]

There wouldn't happen to be a recording or transcript of the AU discussion anywhere, would there? I wish I could have been there because this is something we've been going back and forth on for quite a while.

Does anybody have experience with campus projects that have this kind of combination of units and buildings?
Our latest project is about 20 multi-family residential townhouse buildings and a 3/1 apartment building. The first phase of townhouse budilings have 6 different unit types that go into 8 different buildings in multiple configurations for each building type.

What we are looking for is the most efficient way to have repeating unit files that can show up in a number of buildings, where the insides of the units are consistent but the exterior wall will definitely change from building to building. In our case we really do want interior walls, doors and stairs to be included in this group/link/family and keep our exterior shell in the building file. So I think that rules out the family option.

Originally, we tried using groups for the unit files and then inserting those files as groups within each building file. It works ok the first time but when people update the groups each family gets duplicated when the group is reloaded. One family in one file had 9 copies of the same cabinet. Trying to keep a consistent library of families across 8 different buidlings is proving to be a challenge.

We've abandoned the groups for now and are back to linking the unit plans into the building plans and then linking the buildings into the master file which has the site and all sheets. This is working ok, families are more consistent and fewer components are flipping out into wierd places when mirrored. View management is a pain though. It does seem like we're back to the complexity of layer management in ACAD. So far my thinking is that we'll keep this approach until we hit late DD and convert the links to groups again.

Is there a "BIM way" to do a multi-building project that we're just missing? That "unit maker" idea that Scott had sounds like a great one to me.

Kevin

[Scott Womack]

There wouldn't happen to be a recording or transcript of the AU discussion anywhere, would there? I wish I could have been there because this is something we've been going back and forth on for quite a while.

AS stated earlier in the posts, there were no official recordings of the AU Unplugged sessions. None of these sessions gave "answers". The entire unplugged portion of AU is designed as a peer to peer discussion. This particular topic was mostly divided up into two main camps. Scott Brown did summarize the pros and cons of Groups Versus Links quite nicely in an earlier part of this thread.

[kreed]

I did read the summary of the pros and cons, and I'm not sure what is meant by some of these. "Felxibility" or "Dealing with Documentation issues" under Linking - Pros for instance, and why is "Performance" under both pros and cons of groups?

I assume that the documentation issues are the fact that you have to note and dimension everything in the linked file and try to get everything to show up in the host file. Are there any other issues with Documenation using linked files that are common?

For instance, we're trying to use a master model and to have the buidlings linked in for a fully coordinated set but I cannot rotate a view on the sheet and still have a view title in the proper orientation, at the bototm of the page. Already asked Autodesk about this and they say it's not possible to make a view title family that can go on a different side of the view. Yes, it's a simple problem but it would have been nice to know about before we went down this path.

We have run into a numebr of "performance issues" when trying to replicate groups so I'm not sure what the pro is on Group performance.

All I'm wondering is if there is a little more detail out there about this topic.

[Scott Womack]

I did read the summary of the pros and cons, and I'm not sure what is meant by some of these. "Felxibility" or "Dealing with Documentation issues" under Linking - Pros for instance, and why is "Performance" under both pros and cons of groups?

It is a Con, because if there are too many instances, the file can bog down. IT is a Pro, because you do not have to get out of the main file, to edit the items in a group, it is in the main file already.


I assume that the documentation issues are the fact that you have to note and dimension everything in the linked file and try to get everything to show up in the host file. Are there any other issues with Documentation using linked files that are common?

ANY make that references a view will not come thru out of the linked file, since those views do not exist in hte main file, but only in the link. You'll have to recreate those sections, elevations, etc. in the main file as well. Also, if you have a number of different linked units in your file, opening, and saving to central times may increase, even though your main file size may go down.


For instance, we're trying to use a master model and to have the buidlings linked in for a fully coordinated set but I cannot rotate a view on the sheet and still have a view title in the proper orientation, at the bottom of the page. Already asked Autodesk about this and they say it's not possible to make a view title family that can go on a different side of the view. Yes, it's a simple problem but it would have been nice to know about before we went down this path.

You rotate the callout if that is how the view is made, or you rotate the Crop Region if it is a plan to get it rotated on the sheet, but still have the view title at the "bottom" of the sheet. The plan is rotated, but all annotation, text, etc. is not.


We have run into a numebr of "performance issues" when trying to replicate groups so I'm not sure what the pro is on Group performance.

See Above


All I'm wondering is if there is a little more detail out there about this topic.

Not from this Session.... No offense intended, but I guess you had to be there to get the full impact of the discussion. This was only a 50 minute session, that did not get into specifics/detail on any of the approaches. It was a round-table discussion by 20 or so of the more experienced users discussing their approaches to these types of projects. The final felling was that there is no right or wrong approach. Each project, within each office will have to be thought out and a decision made as to how to approach it. Some swear by the linked apprach, some only want to use groups, and a number of those present use a hybrid approach using groups for units, and then linking in the typical floors, etc.

Good luck on your Quest. None of those preesent found the "holy grail" of methodology.

[kreed]

Thank you, Scott.

We try not to rotate the crop region, so I had forgotten about that one.

[lhanyok]

In our typical housing projects we have been using the group methodology others have discussed. We are now, however, working on an 18 story apartment/condo project, and are undertaking links for the first time.

The units are all defined as groups. I then created a group of each of our two typical floor and pulled those out as two different linked files.

The issue I'm running into is documenting our unit plans. We are doing the dimensioning and tagging (ex. doors) in the linked file and then using "By linked view" in the host model. I understand all of that.

The problem occurs when we need to edit a unit group. Someone made edits to a unit group in the host model. I then used "Load as group" in the linked model of the typical floor where we've documented the unit - however I lose all of my dimensions and tags.

I think our system should be that any edits made to a unit group need to happen in the file where the unit is documented, and then "Load as group" can be used in the other typical floor file. Should dimensions be drawn in the host model?

Thanks in advance for any advice!

[mregan.209424]

I
I use walls that are not attached to the level above, to avoid issues copying from floor to floor levels.
.

Can you tell me how do you get the walls with in the group to change heights with from floor to floor? They are not attached - at 9'-2" high on floor 3 but need to be 8'-10" on the rest of the floor for example.

[nancy.mcclure]

mregan, I would recommend that you create separate groups for the units that have the unique wall height. We create a typical Unit Type group (1BR-A) for all consistent height Levels, and a (1BR-A1) for the taller-wall variant (both have fixed-height parameters for partitions). Many here will advise to create a new group for your Left/Right versions, as well, but we haven't felt the need to go that far (as yet!)