"Sheets" file with linked models

[diamond]

Since you can tag anything across linked files, you could have a "sheets" model that contains all sheets, views, annotations, tags, etc. and all the model files can link into this file where all documentation happens. The intent of this is to further break up the workload on the project to keep fewer people in each file. So, people can be working on the model files, while others deal with setting up sheets, placing tags, dimensions, keynotes, etc. These files should perform better on deadlines when several people need to be in the files. When we get 6 or more people in a large file, the save times get longer and the model performance is drastically reduced.
I am trying this on a large project in the office, but due to some network/IT difficulties, it is hard to tell if it is more or less effective than the traditional route of having your sheets/documentation in one of your model files. Since my evidence of this approach is inconclusive, I would like to know if anyone else tried this and what their experience was like.

[thechunkygentleman]

We are doing this but for different reasons. We have multiple projects on one existing building and the most straightforward way of managing the different project numbers and drawing sheets was to split the sheets and the model. Each project therefore contains just its sheets and references the same main model file. To be honest with phasing involved its a bit of a guddle and far from intuitive for users. I am interested too in whether it would bring performance benefits for a large scheme but i would generally be disinclined to do it again without an experienced team and a damn good reason for doing it.

[Alfredo Medina]

I read this and I have a feeling, like a reminiscence of the CAD days. I imagine people putting tags and dimensions over Xrefs of "master" model files. I don't know if you have tested this enough already, but I think that it might end up in trouble; in order to save some time now, you might end up spending more time later fixing things up. I can't prove it; it's just a feeling. I am open to see what the results are, and I might be wrong; but I would rather have people put all annotations in their own source files, which are linked into the main model, with annotations and visibility already done.

[arb]

I would tend to agree with Alfredo's gut feeling. We've considered going this route on a large complex project but eventually decided that it would be too inefficient and disruptive to our workflow to have most of the content in files that are linked into a "sheet" or "print" file. We have been using linked Revit models extensively for the past few years, and there are still limitations. For instance, producing exterior wall section details with linked information can take longer and be more of a headache than producing the same detail with the information live. Sometimes it's unavoidable, but it's not our preferred method. Also, tagging linked rooms has proven significantly slower than tagging rooms live in the file. I'm still searching for a way to disable this "feature" so that Revit doesn't look for every linked room when I'm tagging. Keep in mind that you can't be in the linked file and host file at the same time (without unloading the linked file) so you'll need 2 licenses to be in both simultaneously. If you go this route I would definitely recommend keeping your annotation in the linked models and use the Linked View option within the host view's VG overrides. Good luck.

- Alex

[Dimitri Harvalias]

use the Linked View option within the host view's VG overrides.
I have a client that has opted for this approach (for a variety of their own reasons) on a large project and, in my opinion, the result is they are doing twice as much work and ending up with greater risk of inconsistency.
You require a rigorous set of naming conventions so the views in the linked model can be easily 'called up' as the views to show in the host model. If you place all your dimensions and annotation in the host model then associations may be lost if the links are unloaded/lost or elements or properties of the link view change. The number of potential issues we uncovered as we were trying to dissuade them from this workflow was astounding and seemed to far outweigh any perceived benefit the client was trying to achieve.
From my perspective, the major pain is that if any model changes need to be made at any time (usually the minute before you plot) need to be made in the link model and since the link can't be open in the same session where the host is open you need to have two Revit sessions open, make changes STC in the link, reload the link in the host and then STC again! Yikes!
Proper project organization and task assignment along with demand loading of worksets can greatly reduce the overhead for users and, although not perfect, keeping all your toys in the same playroom seems to make far more sense to me.

[arb]

Yeah, that's the same conclusion we came to.

- Alex

[diamond]

Well... the project is pretty much done. Like I said, we were having some issues with our "cloud" infrastructure and couldn't judge whether or not the files were faster or slower. The linked view thing seems pointless now that all information can be extracted out of a linked file (via tag, keynote, schedules, etc.). The 'by linked view' workflow involves having 2 sets of model views in each file. More to manage, in my opinion.

For larger projects requiring multiple linked models, you're looking at tagging objects in linked files anyway (if you're not doing the 'by linked view' route). I'm inclined to try this on another large project; surely someone here has attempted this besides me.

[cdatechguy]

The most I do with all the models linked into one is to create overall schedules and my drawing index...most of the time this model is my site plan where I coordinate all my shared coordinates...

I have heard of people actually doing what your asking....but the comments I usually hear from them is the process is very slow depending on how many linked models you have vs your computer hardware.

[bsqwared]

I have worked on a project that did this and I am currently training an office to deal with most of their projects by having a "geometry model" and a "documentation model". There are definietly some pros and cons, the biggest negative being that the information isn't all in one location. However, with the newer interoperability upgrades with 2012, most of that becomes a non-issue. Most offices are still set up in the "Designers working on Geometry" and "Technical guys working on Documents" workflow, which is actually a pro to having your documentation separate. File sizes are more manageable and less people in the models means more stability, but this only matters if the final model is going to be larger than 100mb. Coordinating a geometry model with the consultants keeps the model they use smaller when they link it in. I also think the deliverable at the end of the project is what should drive thisdecision. If you are providing a Revit Model to the Owner or Contractor at any stage, you would spend the time to clean out all of your documentation for legal reasons so they can't reproduce your documents. If you are delivering an RVT file, having a separate geometry model is a great tool. So there is no right answer, it depends on the size of the models, deliverables, and workflow at your office.