Single file vs. Linked files

[pwmsmith]

I need your help,

A great debate is occuring in our office as to the way we use Revit. On the one side a single file is used with all disciplines (Arch, Stu, & MEP) developing a single model for construction documents. The other side is using separate Revit files, one for each disclipine, using copy, monitor and linking the files together. The debate is fierce each side claiming ultimate knowledge. Our company is considered large for the industry and we have all disclipines under roof.

Would you please provide me with an indication of your company size and the direction your company has taken in the direction of a single file or linked files.

Thank You

[twiceroadsfool]

Our current office aside, you would never be able to talk me in to having all the disciplines in one model. They have different needs, they organize models differently, and thats a LOT of people in one file at a given time.

Its no secret that im a pretty big proponent of Linking files together (even JUST for Arch, i link a lot of files together), but there is virtually no downside to it. (I said virtually, there are a few...)

But i certainly wouldnt work multiple trades in one model.

[Gadget Man]

As twiceroadsfool said you can put aside a firm size - it is really irrelevant in this discussion.

For many years I tended to model all my jobs in single files (not very big jobs), with exceptions of the campus-like situations that demanded linking.

I admit I was doing this for a simple reason: lack of knowledge and associated fear of using linked files in Revit in general and sharing co-ordinates in particular.

But once I took a time to learn about linking files and shared co-ordinates I link even simple one-building models with their site plans (which have their linked DWG survey files as well) and will encourage everybody to do so.

True, there is some slight inconvenience of working between different files added to the equasion but overall "cleaningness" of workflow is worth it.

[Scott Womack]

IOn the one side a single file is used with all disciplines (Arch, Stu, & MEP) developing a single model for construction documents. The other side is using separate Revit files, one for each disclipine, using copy, monitor and linking the files together. The debate is fierce each side claiming ultimate knowledge.

I can understand the debate, however, the stated workflow by the Revit MEP group within Autodesk, is for the MEP to link in the Architectural model. In part this is because that work, based upon "systems" has to recalculate the entire system each time it saves to central, or you "Reload Latest". This would tie up the architects from continuing to check out items, or being able to save to central each time the MEP saves.

A year ago I left a 50 person A/E firm with MEP in-house. I am also the leader of the Local User's Group, w/ several firms that are all inclusive in-house. They relate the same information.

[pwmsmith]

Aaron, Jerry, and Scott,

Thank you for your replies, they are greatly appreciated.

I going to need more than 3 replies to sway management,
so can some of you please give me a one or two line comment?

Thanks again..

[Kirk Bricker]

We will be keeping our struct & arch all in the same file. We finished a 175,000SF 1 story Ready Center with arch & struct in a different file and it was a headache (Revit rel. 7-8 ). The walls wouldn't clean up right. We had a few instances with load bearing precast that had a raw finish, and the arch always wanted to move them around, very annoying to have to tell struct to move walls 2".

We just finished a 22,000SF church with struct & arch all in the same file with no problems, MEP was a sub no Revit.

We have always linked in our site plans into our building files and vise versa. It is needed to see what is 10' around the building. When you have a 40 acre site with three buildings you don't want to have all that in one big file.

[josh.made4worship]

Well,

I think it really depends on the project. I know the project we just completed, we have the architectural models split up into 4 peices since we had 4 different buildings. Worked great from a file standpoint, but documenting this thing was a royal pain.

I am talking about having views in the overall file that are set to by linked view which takes forever when you have a lot of views (the arch portion of the set was 230 sheets by itself), and picking up redlines (tracking down the annotation) was a nightmare as well. I mentioned this in another post, but I think we lost 30% production time because of this.

I would say, wherever possible, try and keep as much of the project as possible in the same file you will be creating sheets in for the documenting part. For example, in our case, even though it was 4 buildings, we issued one construction set, so it would have been better (in my opinion) to put all the files together, which is perfectly possible for most projects given you are running 64'bit and have enough RAM. After than, the only major thing you have to wait on is open and save time, and regen time in 3D views (which can be handled pretty easily by turning uneccessary stuff off and adjusting view ranges and crop regions in orthographic views).

Also, as far as Structural and MEP goes, I definetely think, if you are able to do this, putting structural and arch together could make a lot of sense. It may depend though on how structural plans on calculating loads...I'm not sure how 3rd party software like RISA3D, etc. will deal with having the architectural in the model during export. I would assume it will only recognize items set as "structural" in Revit.

MEP should probably be it's own model. But I have heard a lot of firms doing the MEP in ONE model and not having a separate model for each sub-discipline...this cuts down on redundant work of placing equipment for wiring and piping systems, since it can't be copy monitored currently.

One problem not having MEP and Architectural together is elecrical hosting lights and other fixtures to walls and ceilings. Doesn't really work very well. The solution I have heard for the lighting part (and this may freak some engineers out), is to allow the architect to open the MEP model and place the ceilings and the lights, that way they exist in the MEP model, but the Architect still has control over them. This could cut down on redundant work.

I haven't heard of a good solution for host Electrical items on walls. There really isn't a good way to do it to take full advantage of wall hosted objects (when a wall moves, the fixutre moves) right now that I know of. Most engineers are just putting in non hosted objects and praying that the architect doesn't move a bunch of walls!

I hope this helps.

[twiceroadsfool]

MEP should be using Face Based fixtures, instead of Wall Hosted and Ceiling Hosted fixtures. Otherwise theyre going to have problems with not having the Ceilings and walls in their models. (Wall hsoted wont host across the linked files).

Captain35- Im not trying to discount your opinion, but a lot of the new conveniences Revit has with Linked Files (View templates no longer applying to EVERY view setting automatically, Linked Views working in elevation and section, etc) all came about in 2009. Those changes made using Linked files WORLDS better. Load File as Group (2008 i think?) also made distributing content across linked files much better.

The more and more i get in to it, the more im breaking projects up in to more Links for ease of management.

Also, i flat out REFUSE to put disciplines together in one model. The seperated models keeps everyone honest about whos holding the bag in which situation. Engineers cant on-the-whom move design elements around, and architects cant willy-nilly shove beams and joists around either. It keeps people honest.

View management and content management is additional work, when the files are all linked. But once the team understands how it works, it becomes second nature.

Quite simply, its the only way to fly. :)

[josh.made4worship]

Aaron,

I know where you are coming from, but I don't entirely agree. I think that with Revit needs and eventually will become more calloborative efforts in which "holding someone accountable" shouldn't be an issue. The bottom line to me is that is obvious (even though we don't have the capabilities yet) for a BIM model to contain all the information necessary to build a building, and accurately. When MEP guys are having to place duplicate light fixtures to get there stuff to work right, that's crazy!...not to mention the model and IFC data will contain this information. I know that's the necessary workflow now, but I'm just saying that it's not the way Revit was intended to work in the long run.

I think there could definetely be given some more useful tools for linking views that would expidite the process, but I got very good at view linking the last project I did, and it didn't change the fact that it took forever.

Anywho, I think it's great that you have perfected the file linking workflow! I think it would work a lot better for MEP guys if Revit had a few more tools though...I think this is where a lot of the battle is coming from. Architecturally, it's not too big of a deal. But even if you are using a face based electrical outlet, if the architect deletes that wall for whatever reason, the outlets go away in the MEP file...

This makes some sense, but I have seen reason architecturally while trying to laying out walls, that you would delete a wall, just to redraw it in a similiar location. If this happens, those fixtures will dissappear since they were hosted to the previous wall.

There are a lot of frustrating issues for them that I am sure you are aware of, and it makes the whole linked/not linked arguement a big mess.

I am a big proponent for all the data in one file...for me, that's true BIM. Unfortunately, our software package is quite there yet, so we wait in anticipation.

I can't wait for the day, when I can put some 3D goggles on and build a building in virtual reality...!!!

[twiceroadsfool]

Aaron,

I know where you are coming from, but I don't entirely agree. I think that with Revit needs and eventually will become more calloborative efforts in which "holding someone accountable" shouldn't be an issue. The bottom line to me is that is obvious (even though we don't have the capabilities yet) for a BIM model to contain all the information necessary to build a building, and accurately. When MEP guys are having to place duplicate light fixtures to get there stuff to work right, that's crazy!...not to mention the model and IFC data will contain this information. I know that's the necessary workflow now, but I'm just saying that it's not the way Revit was intended to work in the long run.

Duplicate light fixtures? Why? Were working with MEP consultants now in seperate files, and we dont need duplicate fixtures. We put in placeholders before they got involved, so they knew where lights were going to go, but we would have done that regardless. And they would have had to replace them with the right fixture regardless, as well.

People get too hung up on thinking the "BIM" needs to all be in one file. "BIM" is a collaborative process, that happens over time and in many file formats. Hell, the structural DESIGN model might get done in Revit, but its out the window once shop drawings start anyway, and then its the fabricators model. IE: Your "BIM" has two structural models. There is overlap everywhere. BIM is much more than "one file that has one of everything." Its an entire lengthy process by which we work.

If you like it all in one file, more power to you. :)




I think there could definetely be given some more useful tools for linking views that would expidite the process, but I got very good at view linking the last project I did, and it didn't change the fact that it took forever.

Id be really curious to hear what took so long. The last three jobs ive done have all been through Linked files and Linked views, one with 14 models. We linked views all day long, managed it with view templates, and the job was done in record time.




Anywho, I think it's great that you have perfected the file linking workflow! I think it would work a lot better for MEP guys if Revit had a few more tools though...I think this is where a lot of the battle is coming from. Architecturally, it's not too big of a deal. But even if you are using a face based electrical outlet, if the architect deletes that wall for whatever reason, the outlets go away in the MEP file...


Thats not really true... It depends on which option they select in terms of HOW to place the FB family, in the Option bar (or whatever its called now). They have to specify Work Plane / Face / or a third choice that isnt always there (i forget what it is). I *think* the option you want is Face, but i always get them confused. When you pick the right one: if an Arch wall MOVES, your fixtures go with it automatically. If the Arch wall gets DELETED however, your objects remain with an undetermined plane of reference.[/quote]


This makes some sense, but I have seen reason architecturally while trying to laying out walls, that you would delete a wall, just to redraw it in a similiar location. If this happens, those fixtures will dissappear since they were hosted to the previous wall.

There are a lot of frustrating issues for them that I am sure you are aware of, and it makes the whole linked/not linked arguement a big mess.

I am a big proponent for all the data in one file...for me, that's true BIM. Unfortunately, our software package is quite there yet, so we wait in anticipation.

I can't wait for the day, when I can put some 3D goggles on and build a building in virtual reality...!!!

Eh, see my paragraph above. Where do you draw the line? By "BIM" is all in one file... But its an NWF file. And that NWF is comprised of several NWC's, and an IFC or two. Its not realistic to say a "BIM" is an RVT file, since then its only usable in Revit. The beauty of getting files to COLLABORATE is that then even the owners can use the "BIM" for their uses. Id keep writing, but im late, LOL...

[sven.129574]

I know I'm chiming in way too late on this, but we hate using linked files. There is just too much stuff that doesn't work right, including:

VG issues. Each discipline winds up having to go into the architectural file and set up views just for themselves, because there seems to to be too many little issues with graphical appearance that don't work right otherwise (things not trimming at the view boundaries, VG not working right in this special situation or that one, plotting issues, etc.). Just because you use linked files doesn't mean you get out of having to go into the other discipline's files, and just opening and saving those files adds hours over the course of the project.
Hosting issues.


MEP should be using Face Based fixtures, instead of Wall Hosted and Ceiling Hosted fixtures. Otherwise theyre going to have problems with not having the Ceilings and walls in their models. (Wall hsoted wont host across the linked files).

That's correct; wall-based, floor-based, and ceiling-based families can't be hosted to hosts in the linked file. The trouble is, we find that face-based fixtures suit our needs maybe 40% of the time. Where is the face-based light fixture family template? There isn't one, and you can't copy a light source from one family file to another one, either. Ever try to create a face-based family that has a symbolic representation in plan? I mean a symbolic representation that is always the same size on the sheet, like an exit sign or a smoke detector, not something like a troffer, where the graphic is supposed to scale with the size of the ceiling grid. You can't necessarily place the annotation in the view of the family editor where it needs to go.

Working in one file means that you can use wall-, floor-, and ceiling based elements much more often, though decent face-based functionality is still needed sometimes. Sometimes you need to host something to a column, mullion, stair, etc. Face based family functionality is still a problem Autodesk needs to address.
Copy Monitor Pains. C/M only tells you about deletions and modifications, not new additions. And only a few kinds of elements can be copy/monitored at all. Notable omissions include ceilings, beams, lights, and sites. But then again, even the small set of elements that can currently be C/M'ed can be information overload. Might be better to just ignore C/M.
Duplication of work. The architect probably showed you where she wanted the light fixtures. Instead of placing your own fixture where each of hers is (Did hers cut holes in the ceilings? If so, you'd better duplicate her ceilings, too!), wouldn't it be simpler to just circuit hers? Or swap hers out for something better, and circuit those? Even if you have to move or replace some of the fixtures, there are probably some in the right places. Why do something over if you don't have to? The only caveat is that you need to make sure that the architects use MEP families -- otherwise they may not have all the necessary functionality.All that having been said, there are still situations where there is no alternative to using linked files, including:

When one of the disciplines involved in the project is working in Revit out-of-house.
When the .rvt file is too big for one file (around 120-160MB for us; YMMV).
When there are going to be more than about 5 or 6 users working on the file at the same time (too many users cause a save-to-central logjam).I keep hearing users say stuff about how "the intended workflow that Autodesk recommends is to use linked files." But everything I've ever read from Autodesk says that they support either a single-file or linked-files workflow. We find the single-file workflow much smoother, but not always possible.

And speaking as someone who has actually, literally written a dissertation and a number of peer-reviewed research papers on object-oriented representations of building elements over the sourse of the last 15 years, I definitely believe that a single-model approach is the future. Building componets don't just affect one discipline -- they have implications for multiple disciplines.

[twiceroadsfool]

I tend to try shying away from arguing/debating about Linked Files. I use them with great success, and a lot of people dont like them. Bottom line is, if you dont like them, dont use them. But im at least going to clear up some misconceptions for the new users wondering about using Linked Files.




I know I'm chiming in way too late on this, but we hate using linked files. There is just too much stuff that doesn't work right, including:

VG issues. Each discipline winds up having to go into the architectural file and set up views just for themselves, because there seems to to be too many little issues with graphical appearance that don't work right otherwise (things not trimming at the view boundaries, VG not working right in this special situation or that one, plotting issues, etc.). Just because you use linked files doesn't mean you get out of having to go into the other discipline's files, and just opening and saving those files adds hours over the course of the project.


Im not sure what kinds of problems youre having, but i have to call it Operator Error. Ive done a BUNCH of projects of varying scale AND complexity, with all trades working in Revit. Too date, i can count the number of times ive had to open a consultants file on one hand, and even in those instances it was simply so i could make a change in their model that i knew was coming in the next iteration, and i just wanted to print ahead of time.




Hosting issues.

That's correct; wall-based, floor-based, and ceiling-based families can't be hosted to hosts in the linked file. The trouble is, we find that face-based fixtures suit our needs maybe 40% of the time. Where is the face-based light fixture family template? There isn't one, and you can't copy a light source from one family file to another one, either. Ever try to create a face-based family that has a symbolic representation in plan? I mean a symbolic representation that is always the same size on the sheet, like an exit sign or a smoke detector, not something like a troffer, where the graphic is supposed to scale with the size of the ceiling grid. You can't necessarily place the annotation in the view of the family editor where it needs to go.


I have a Face based Exit Sign family that does just that, as long as the Exit sign is oriented appropriately. If its on a canted wall, so the annotation doesnt show up in the Floor plan, its because its not perpendicular to the plan. It works with a wall hosted family because the WH family hosts improperly, and gouges out the wall.



Working in one file means that you can use wall-, floor-, and ceiling based elements much more often, though decent face-based functionality is still needed sometimes. Sometimes you need to host something to a column, mullion, stair, etc. Face based family functionality is still a problem Autodesk needs to address.


In a perfect world this is true, but there are TONS of other issues working in one file DOESNT address. As designers, we sometimes delete a wall then replace it, instead of editing or manipulating the wall. Do that while three trades have hosted stuff to your wall, and watch them b**ch and Moan about how youre unraveling their work. Now, im not condoning deleting walls instead of editing, but im making the case that its a lot of hands in one pot, if youre NOT an integrated AEC firm thats sharing all of the contractual obligations. Flat out, i dont want consultants manipulating things im responsible for, unless theyre on the hook WITH me.



Copy Monitor Pains. C/M only tells you about deletions and modifications, not new additions. And only a few kinds of elements can be copy/monitored at all. Notable omissions include ceilings, beams, lights, and sites. But then again, even the small set of elements that can currently be C/M'ed can be information overload. Might be better to just ignore C/M.


This, i wont argue with. CM needs a ton of work, but its still a tool with great potential. We use it a lot on our projects, but it certainly needs work.



Duplication of work. The architect probably showed you where she wanted the light fixtures. Instead of placing your own fixture where each of hers is (Did hers cut holes in the ceilings? If so, you'd better duplicate her ceilings, too!), wouldn't it be simpler to just circuit hers? Or swap hers out for something better, and circuit those? Even if you have to move or replace some of the fixtures, there are probably some in the right places. Why do something over if you don't have to? The only caveat is that you need to make sure that the architects use MEP families -- otherwise they may not have all the necessary functionality.

Again, great in theory. Except you (as the engineer) are going to have to go in and edit them anyway. Architects/designers are going to put lights where they think lights go, and theyre generic lights. Theyre not messing with lumens/wattage/light colors. So youre changing them anyway. I DO agree that it would be fantastic for CM to handle cases like this better, but i dont suscribe to the "only one trade can show it" philosophy of building a multi trade model. Our lights are there to show layout and concept, your lights are there to show function and wiring.



All that having been said, there are still situations where there is no alternative to using linked files, including:

When one of the disciplines involved in the project is working in Revit out-of-house.
When the .rvt file is too big for one file (around 120-160MB for us; YMMV).
When there are going to be more than about 5 or 6 users working on the file at the same time (too many users cause a save-to-central logjam).I keep hearing users say stuff about how "the intended workflow that Autodesk recommends is to use linked files." But everything I've ever read from Autodesk says that they support either a single-file or linked-files workflow. We find the single-file workflow much smoother, but not always possible.

And speaking as someone who has actually, literally written a dissertation and a number of peer-reviewed research papers on object-oriented representations of building elements over the sourse of the last 15 years, I definitely believe that a single-model approach is the future. Building componets don't just affect one discipline -- they have implications for multiple disciplines.


Im not going to get in to a "who-knows-more-because-we-wrote-papers-in-college-on-XYZ," but while you may have written some great papers, understand that some firms ARE using Linked Models with PLENTY of success in multi trade (and single trade) environments.

So while we may disagree on how easy and efficient it is, lets not tell new users that the process falls apart doing it as such, when plenty of people are actually doing it with great success, and quite easily. :)

[cliff collins]

In our projects, which are very large and complex, it is basically IMPOSSIBLE
to have everything in a single model/revit file. Hardware, even in 64 bit environment
with 8-16 GB RAM, dual quad cores, etc. just can not keep up.

It's not a choice--these files MUST be linked.

Example project we are currently working on.
Over 1 million square feet.

A 250 MB Shell and Core model-Tower
A 175 MB Shell and Core Podium model
A 200 MB Interiors Tower model
A 150 MB Parking Garage model
A 250 MB Podium Interiors model
An 85 MB Site model
A 90MB Revit Structure model
A 110 MB Revit MEP model

Do the math. Good luck having all of that in one model.
It's a challenge even for Navisworks.

Scheduling and Sheet management across linked files becomes the issue.
And working across a WAN.

This is why you HAVE to link models on large projects.
And use 64 bit software, OS and hardware with lots of RAM.

cheers.......

[ktracy.194130]

In our projects, which are very large and complex, it is basically IMPOSSIBLE
to have everything in a single model/revit file. Hardware, even in 64 bit environment
with 8-16 GB RAM, dual quad cores, etc. just can not keep up.

It's not a choice--these files MUST be linked.

Example project we are currently working on.
Over 1 million square feet.

A 250 MB Shell and Core model-Tower
A 175 MB Shell and Core Podium model
A 200 MB Interiors Tower model
A 150 MB Parking Garage model
A 250 MB Podium Interiors model
An 85 MB Site model
A 90MB Revit Structure model
A 110 MB Revit MEP model

Do the math. Good luck having all of that in one model.
It's a challenge even for Navisworks.

Scheduling and Sheet management across linked files becomes the issue.
And working across a WAN.

This is why you HAVE to link models on large projects.
And use 64 bit software, OS and hardware with lots of RAM.

cheers.......

Cliff,
How are you handling the document set with regards to section/elevation/callout tags? Is everything annotated in one file? Are all the sheets in one file?