Does your firm work on large residential projects in Revit? If so, how do you organize the model(s)? Do you use groups for the units? How about rooms inside the units? What tips or tricks have you learned? What things are you still struggling with?
Share your experiences in the comments below.
For a 200-unit apartment/mixed-use complex with 2 buildings, I created a shell model for each building (with demising walls), a unit model for each unit type, and a site model that hosted the other models. Using a unit model for the approximately 18 unit types saved us from the many issues that using groups would have (potentially) caused. Editing groups spawn additional groups and it can quickly spiral out of control. When we edited the units, it was a simple matter to reload them into the shell model and all instances would update at once. I’ve done similar approaches to large hospitals.
You used best practices that Revit was designed for instead??? are you mad?!?
Interesting! Did you run into any issues managing the various unit type linked files?
No issues that I recall. Some of the unit types even spanned floors. We used room separation lines to act as a placeholder for rooms in lieu of the demising walls in the shell model. This was around 2013, so perhaps the grouping tools have gotten less problematic. For us, it was far easier for someone to wreck a model group, or create multiple unintentional new groups. We could even build-in reference planes that extended through the shell model exterior walls that we could align a stretchy balcony to because the width varied depending where on the building the balcony occurred. It worked well for us. Happy to hear that some are successful with model groups. Cheers!
Eric, I’m totally with you, but still struggling somehow:
We are working with links on a big residential model, 50 apartment types (each one in as a separate link) and around 230 units all together.
We couldn’t work with whole floors as inks because the units are typical, but the floors layout isn’t.
We are experiencing issues with a veeeery heavy, slow model.
When other consultants link this main apartments model, they also suffer.
All links are in good shape, it just seems like the fact there are so many links effects the main model performance.
No way we move to working with group, they will probably cause more issues.
Any thoughts about how we can improve things?
Try to workset your levels. When worksets are turned off those items are not read by the model and so they don’t affect your PC’s memory. This way you can open only the levels you are working on, and only open everything when you need to. Not a total solution but may help.
Hi Eric,
I would be interested to hear if you fully annotated and ‘viewed out’ the linked units…? Our firm is steadily moving through the Units, Model Groups vs. Links, murky water.. Not wanting to blow up the conversation anew, however, just want to see if your workflow included annotation, and if so, you would have updated each view in the host model showing linked view.. We are contemplating this step for our unit library.. . providing all kitchen elevation views, fully annotated and keynoted.. In the elevations it is good and fine, however in the plans, if the enlarged view is a different rotation than the library set, then needs to be re-keynoted fresh in the model to keep the orientation. The nice thing is we are using the same keynote file for all models in the project, so, the keynotes go quickly…
Would be interested to hear how far you took the unit models.. Kindly, Bryce
Lots of large multi-family high-rise projects (and student housing) here.
We’re the opposite – units are model groups. That way they’re easy to modify and update without opening separate instances of Revit to revise a linked unit.
We’re pretty strict in how model grouping happens so it doesn’t cause instability or end up with lots of “excluded elements” from the groups.
Rooms are just a single room for each unit for scheduling purposes, not individual rooms within the units themselves.
Thanks Andrew. I was curious about using “rooms” to delineate units. How do you deal with doors and finishes inside the units?
Hi Andrew I agree model groups are far better than linked instances. When you say single room for unit it means you make all walls are non room bounding inside the unit? Do you include rooms in the group?Do you guys calculate / generate light and vent schedule in Revit?
I’ve probably done 10+ multifamily/hospitality projects in the last 2-3 years. All done with the model group method. Much prefer it over editing and reloading linked models constantly.
The only time I ran into problems is when someone hosts something to a wall outside the model group (demising walls are outside of the group). But other than that, you can almost always solve the dreaded ‘fix mode’ popup by looking at the error and fixing it.
We are the largest multi-family firm in the country. I say this just to give an idea of how many units and models I’m dealing with. As BIM Director, one of my first major changes was to switch to groups and a single file. Everything comes down to money, so there is no single solution for all. If our timelines were much longer, I may have stayed with links, but with production speed and budgets being a priority, we will stick with groups. There is a whole science to creating them in a way that avoids “fix groups” error. That’s a separate conversation…. not difficult to implement.
For high rise apartment buildings near 300 units, 36 unit types, we use groups, I tryed different ways, the unit with the envelope and demising, in one and two groups the interior nested in the exterior, the unit with demising and corridor with the shell independent, the eternal issue FIX GROUPS! A real nightmare, apart when have different height between slabs, we tried different ways, alternates for that ( I don´t like, plus when you have 36 unit models), or the other, attach the wall to slab, because revit don´t works automaticaly slab to slab in different instances, any solution?
We do 100-200 unit apartments and condos primarily, and have had the most success with model groups. Because of our client base, we end up reusing most of the model groups in other projects. The process of copying them into the new project, cleaning up the groups, and tailoring them to the new project is very quick. We also keep the room to the perimeter of the unit and simply label the individual rooms on unit sheets with text blocks.
For MEP, groups simply don’t work for dwelling types when copying around. I think it is partly because hosting elements are outside of the group. I’ve tried hosting on reference planes and adding them to the group but this still doesn’t work smoothly. Hosting’s get lost, editing groups cause issues. We’ve also tried separate links which is fine for a small number of types but we can have projects with 3 or 4 blocks with 20-30 different dwelling types in each. Document management becomes critical.
To summarize the long explanation below, the methods I’ve used and the results are as follows:
1. Each Unit Type modeled in main model, exported to CAD, imported to family, inserted in main model and propagated through the building. Results: cumbersome workflow leading to lack of upkeep and inaccurate building models. Do not recommend!
2. Same method as above with the addition of Unit container files for modeling and documentation, and groups of like configurations used. Results: Same as above with the added headache of maintaining multiple models for sheet production. (We also ran into a major snag with permitting due to the sheet naming convention.)
3. Still using container files, this time grouping the unit types with nested groups of kitchen/bath configurations, inserting the groups into building model. Results: Disaster of epic proportions due to inherent group constraints, a bloated model that constantly crashed and difficulty coordinating with MEP and Structural. DO NOT USE THIS METHOD!!
4. Continued use of unit container file, but only for initial unit creation. Continued use of groups for typical kitchen/bath configuration during design development, but groups were converted to links with units becoming individual files with nested links which were then inserted in main building model and distributed.
5. Container files for units only used for initial schematics. New Unit Template created to standardize unit content. Like-bath and kitchens are separate, individual models linked into units which are annotated and then linked into building model with enlarged unit plan graphics set to By Linked View. Results: Successful but does require in-depth knowledge of unit features and regimented upkeep. Highly recommend unless something better comes along. See below to follow the progression of each method.
At my previous firm we focused on Senior Living – Independent, Assisted and Skilled Nursing. The process is very similar to multi-family housing (with a much more stringent code). When I first joined the firm Revit use was in its infancy with few staff members having any proficiency in the program and the project I was hired to work on was the first three multi-story buildings on a brand new campus in New Jersey. I was responsible for creating and documenting all of the living units in all of the buildings along with marketing materials for the Owner’s sales team. The schedule was ludicrously tight and we were severely understaffed for the project. On top of that, I had never worked on this type of construction and the other team members had never worked in Revit on this scale. We were using Revit 2013 or 2014 for the project, Structural was in Revit, but MEP was in AutoCAD. Both Structural and MEP were outside consultants and model exchange was being handled by e-mail to begin with, switching to ShareFile when we were well into CDs. These models quickly became overweight and unwieldy as there were multiple CAD files and groups. The solution for the units was developed before I came on board, unfortunately. The workflow was to model each unit configuration, export the unit to CAD, insert the CAD into a family, and load it back into the model then place the family throughout the building. The first problem was making sure the workflow was maintained when any changes were made to the unit so that the families were updated appropriately and the changes were reflected in the building(s) where the unit was located. The second problem was the requirement to create a new unit for any slight differences – even if it was because a column wrap was visible in the living room due to the location of that unit. There were so many of these tiny differences that we ended up having over 40 different Independent Living units alone, plus the additional Assisted Living and Skilled Nursing units. Trying to keep up with the changes being made to units on an almost daily basis was difficult enough, then those changes had to be propagated to the families and back to the buildings. Insertion of the CAD drawing into the family had to be precise so that the insertion point didn’t change. Then the marketing plans had to be updated with the detail elements (fill patterns, dumb area tags and annotations) adjusted appropriately. It was a nightmare.
The next phase (two more Independent Living buildings) began while the first phase was under construction. The same units were to be used which meant any changes that occurred in the field had to be incorporated into the new phase as well as the first phase. I wasn’t working on the project by then and the workflow for the changes was not being followed. The modeled unit may have been modified but the following steps didn’t take place so that the changes weren’t being made throughout the building. They also started using a new method of creating a container file for the units with kitchen and bath configurations grouped so that when a change occurred in a configuration it only needed to be changed in one place to update every occurrence. It was also decided to document the units in the container file and produce Construction Documents for the units from it as well. The units were still following the workflow of export to CAD/insert in family/insert family in building model and the same issue with not keeping the building model up to date was still happening.
By then I was working on a new project for the same client and a new workflow was implemented. This time, the unit configurations were modeled and grouped with the groups placed throughout the building. This impacted the size and performance of the model considerably. In addition we had nested groups of kitchen and bath layouts. Some units were unique but had the same kitchen and/or bath. Problems occurred with mirroring or moving the units or kitchen/bath groups because of wall hosted elements and the general constraints you have when working with groups. The model was constantly crashing and our MEP consultant couldn’t even load the link due to the size.
The final project I worked on for that client was phase three of the original project. By this time we had thrown out the Model-CAD-Family-Model workflow and the groups workflow was verboten. For the Schematic phase, the 2d CAD files were used. I’m not sure if we even used the conversion to family step. We started out with the container file method to develop the units with groups for kitchen and bath types and then the grouped the units. Then we exported the units as links bringing the links into the building model. This worked to some extent, but the building model was still very sluggish. Once the unit layouts were nailed down, we decided to export the kitchen and bath groups to links and nest the links into individual unit models. We also determined it was better to annotate and keynote the links, then use Visibility Graphics of By Linked View to show the annotation. We discovered that annotations would be lost if the unit was keynoted in the main model and the link was unloaded or moved which was a very painful lesson involving a lot of re-work. We had also slimmed down the families to 3D linework with 2D plan, elevation and section detail components. Nothing was wall hosted or face based and Reference Planes were used in the unit links for exterior, demising and corridor walls to be used for dimensions as we found dimensions to nested links would not show up in the linked view. This method required great attention to detail and tracking of what nested links went with which unit and to make sure all were updated appropriately. All-in-all, I think this method worked the best as long as the unit layouts were nailed down in the Design Development phase rather than having a lot of changes occurring once documentation was well underway.
for any type of residential unit I use Model groups. only the internal walls, elements such doors, plumbing, Case work and rooms are part of the group. room tags are placed per view as required. balcony and window element are part of the perimeter groups repeated as required. Although Number of Groups are more but that is manage by strict naming convention. it gives a lot of flexibility when there are inevitable edits required. also wall height are fixed so no issues when there are varying slab heights & hence FIX GROUPS! issue is also minimized.
We’ve tried both methods and ended up using a hybrid strategy. When we used model groups, we ended up with corruption & duplicate/inconsistent groups. When we used individual unit files, we had to make updates to 20+ files in order to make a simple change to any schedule information, and it was also difficult to keep units using the same families if any edits were made after the separate unit files were created.
Our new process has two working models & a folder full of unit exports. We create a file with one model group of each unit (kitchens & bathrooms are families with shared nested families within the groups). These groups include any objects within the “core & shell” of the building (finish floors, ceilings, furniture, kitchens, bathrooms, non load-bearing partitions, interior unit doors). All of the schedule information for the units gets updated in this file, and all of the units use the same families. Revit also lets you make changes to all the units because there’s only one instance of each group. These groups get saved as individual RVT files (“Save Group” or “Save As – Library”), and the individual RVT files get linked into the main project and copied throughout. You’re able to attach detail groups during the export process for enlarged plan & RCP information that then can be seen in the main file “by linked view”. We keep the unit file as groups throughout documentation and rely on exporting the units and reloading the links to update the main file / documentation.
It definitely has some limitations, but it has been a good solution for our larger projects so far.
That’s an interesting approach! I’ll have to test it out. Thanks Ruth.
Hello Ruth,
Have you faced any issue in the individual group(s) rvt file object styles & line weights ?
Our firm produces 200-700 Unit Multi-Family/Mixed Use, Student Housing and Senior Living projects and found that creating model groups works the easiest. Others have mentioned the dreaded hosting issues with elements attaching to non-grouped elements (towel bars, upper cabinets, etc. at demising walls), we resolved these by creating non-hosted elements. Upper Cabinets still function the same way and are then simply aligned to a non-grouped wall and our “Fix Groups” messages are vastly reduced…..where our Unit Doors are concerned, these are numbered per the Unit (all Entry doors are U1, Bedroom U2, etc.) with a Door Unit Type Parameter coded as U1, U2, etc. We can then easily create a door Schedule for Units only. All interior walls of the Units are Non-Room Bounding, Units are tagged on our plans as Unit A1, Unit B2, etc. On our enlarged Unit Plans we use simple text for individual room names within the Unit. Sounds like we are all doing very similar procedures. We have tried Linked Files and while they do have a lot of merit, we have found it easier to work within the model on Unit Groups.
There is an autodesk university class on massive multi family housing projects done by Kelvin Tam that evaluated all these options and some more unique approaches.
I’ve done a boatload of multifamily projects over the last 26 years with most done in Microstation. I started using Revit with 2009 but didn’t make the “no turning back, now!” change until 2013 and use it exclusively. I have tried all of the above methods and experienced most of the same results–some worse, some better. BTW, these question could also apply to hotels.
The method that has been the best for me is similar to what Ruth wrote. The best use of a method like hers worked for stair towers. Revit stairs suck, especially the way they show up in section: “No, idiot program, I do not what to end with a riser!” I got a stair tower perfect with gypsum on the underside of the stairs, railings, etc., saved it out, and PRESTO! I had a tower I use in apartment complexes and hotels. The only caveat is it was done with 2015 Revit, and makings changes and importing has broken down with every Revit “upgrade” since. Still works, but…
Based on what you include, Groups are fine and dandy, UNTIL you get into asymmetrical wall assemblies like UL U327 (1-hour, STC 51-53) and UL U334 (2-hour, STC 62-65). Examples using 2×4 construction:
U327 – 5/8″ Type X gyp–2×4 stud–1/2″ RC-1 channel–5/8″ Type X gyp
U334 – (2) Layers 5/8″ Type X gyp–2×4 stud–1/2″ RC-1 channel–(2) Layers 5/8″ Type X gyp
I do low-income where the developer tries to squeak by with the standard U305 or U301, but there’s a minimum dwelling and sleeping unit separation STC of 50 (2015 IBC 1207.2). In more upscale apartments, they want an STC of 50++ for bedrooms.
I’ve had problems using center or wall, center of core, “interior” face, and “exterior” face with the FIX GROUPS, DAMMIT! error. Using “interior or exterior” of core has guaranteed madness. Even the most minimalist groups can cause problems, especially if you have to mirror wall partition for whatever reason (eg.: RC-1 would be on both sides of the interior of a room).
Honestly, sometimes it works, and sometimes all hell breaks loose, especially when floors are included (where is the floor demarcation?). This is one part where Ruth and I are different. Asymmetrical walls + floors can be utter madness at times when mirroring/copying groups.
Anybody have this problem? Any suggestions?
We use model groups for units, with rooms included, with room bounding demising walls outside of the groups. We use Area Plans as our GA plans so we can have room areas and flat areas on the same drawing. The downside to this is you can’t use reference tags next to the matchlines on area plans that are split by dependent views, but we don’t see this as a major disadvantage.
The biggest thing we struggle with is how to split up large models. We have done this previously by creating a separate model for each core block and linking them to a “master” model from which all views are taken and sheeted up. This way a detail common to all blocks in the building can be tagged effectively without the need to create dummy tags. It also keeps a tidy project because all sheets are taken from one model and everyone knows where to find a specific sheet. However, the master model tends to become huge in file size, sometimes significantly over 500MB for a 400-500 unit scheme!
For the next project I am thinking about creating GA plan information from each core block model and using the federated architectural model for elevations, sections and details to try to reduce the file size of the master model.
I have worked on stadia before, and splitting these models into separate roof, external envelope, seating bowl, internal layout models etc works well because each element is sufficiently different and there are usually no common elements which share common details, but to me it doesn’t suit residential blocks.
I would be interested to hear how other firms deal with splitting up large residential project models, but in the meantime I will look at the Autodesk University class on massive multi family housing projects by Kelvin Tam as recommended by Dan Bush above.
We’re a small Architectural Practice in the UK. Our main projects are residential housing developments of between 10 and 50 houses. We have a couple that are over 200. We use a separate Revit model for each house type, which are linked to a site plan. This mostly works well, we have small problems where a house type has multiple exterior finishes. These could be cladding/render colour or even areas of cladding and no cladding etc. Using design options is alright for the modelling aspect, but the management in the site file with many instances of each link and ensuring the links are showing the correct design option can be a bit of a nightmare. When the only differences in house types are colours of finishes, I’ve been using filters rather than design options to change the colour in a view. The only problem so far is that I cannot filter by Revit Link Name or Revit Link Comment to allow the filters to be applied to specific house plots. I don’t suppose anyone has any ideas that I have not tried? The majority of works people seem to be carrying out while searching for residential projects in Revit are apartment blocks.
we have similar, tip use dynamo! and manage the worksets.
A general follow up on this topic, re the following.
For multi-unit housing, how are you tagging Units and how are you scheduling the units/rooms/areas. .
Because you can’t tag a model group, and the units may already have multiple rooms, how are you handling the units?
I have been looking at an area plan overlay onto the floor plan to display the tagged units as areas, then rooms for everything else, as well as the individual unit rooms. . .
Step one: https://blog.testfit.io/
Step two: http://autodesk-revit.blogspot.com/2013/05/scheduling-apartments.html
I recently downloaded TestFit, total game changer earlier on in the schematic phase. Couple that with Revit and Enscape and the schematic phase is done in a few days, ha.
I have worked on several large residential projects and the method for model management we have settled for after a lot of trial and error is the following:
Repetitive units such as bedrooms are modeled as independent files (we found these more maneageable than groups), then linked into repetitive stories models (eg. we have 10 bedroom models randomly distributed in about 8 different repetitive stories which in a different model pile up to conform the final tower of about 30 stories.
In the bedroom files we manage small changes (like column size decreasing as the building goes up) using design options. Its is crucial to plan which changes are fit for design options and which are best managed by creating a different file, since these changes will not be able to be scheduled in the tower file (after passing through the repetitive stories files) and only the main option will prevail in the schedules.
For graphic purposes we create in the repetitive stories models the basic views (adjusting the bedrooms design options) which are going to be summoned next in the tower file using “by linked view” option.
In our work flow, we have many copies of this tower file, each for documenting a different topic. This way we separate the sheet producing work from the modeling work and thats a huge saving in model size and management. The down side is design options in the bedroom files can not be scheduled in the tower file, after going through an intermediate step in the repetitive stories model. Planning is crucial in this aspect.
What I have described to this point is the Architectural work.
MEP repeats the Architectural file structure only adjusting design options in the bedrooms. By breaking MEP systems into repetitive plans we accelerate documentation but lose systems consistency. As we are always in fast track delivery we have preferred to gain speed and lose a bit data.
Structural engineers have 1 or 2 models depending of the buildings complexity. They reinforce and document in those same files.
Also, in the bedroom models we create different rooms designating bathrooms, living, wardrobe, balconies and so on. Once these model are placed and arranged in the repetitive stories models we set them to be not room bounding, and using the main story walls and some room separation lines (if needed) we enclosure and create a room that spreads through the entire bedroom, dissmissing the internal divisions. This is the room we give the final data, such as commercial name and number. Using this approach we can tell what elements belong to which part of the bedroom (this is a client requirement). But we still need a way to tell in which level these large rooms are, as they are placed on top of one another in the tower file. To address this issue, in the rooms category we create as many shared parameters as stories has the buildings, each will have the room name according to the level prefix (eg. 1-105, 2-105, 3-105…). To round this up we create a tag that has a visibility parameter for each of these shared parameters the tower, so we can display levels correctly.