Worksharing for a Campus Project

[dominicsy]

Hi all,

Our office is new to Revit (under 6 months); we have a 3 building campus project that's about to go into design development that we want to implement worksharing to. I'm trying to get advice on the best way to go about this.

The project is currently split up into 4 files, one for each of the buildings, and 1 site file where we link our building files to and do site plans and renderings for the overall campus.

Our leader wants to have common materials, dim styles, tags, families, view templates etc. and suggests we merge everything into 1 central file and split up the project into worksets. So maybe 3 worksets for each of the buildings, and each can be further subdivided if possible? This idea seems good to me in theory, but I'm worried about file size, as it stands now, each building file is hovering around the 50 - 60 MB mark.

My idea is to keep the 3 building files separate, split up into worksets, and all linked to the site plan for overall drawings and renderings, and just use the Transfer Project Standards tool for the common elements. This should keep file sizes manageable, make the transition into worksharing a little simpler.

What should we do? We have the time right now to set up the files properly, so I'd rather go for the option that will benefit us the most in the long run.

I'm open to advice, tips, experiences any kind of help... Thank you in advance.

[sbrown]

Sep Building = Sep. model. Don't combined them in my opinion. Assign someone to oversee the transfer of assemblies from one model to the others. Use schedules(walls, roofs, floors and ceilings, etc) to see if you have "non-standard" types and replace them as needed.

You will still want to enable worksets.

So you will have 1 site model, 1 building model(worksets for core and shell and interiors) for each building. Note when linking into the site model only link the core and shell workset.

[twiceroadsfool]

100% agree with Scott.

Each building is a seperate model. Someone will have to manage the content, to make sure when families get updated / walls get updated / materials get updated, that it gets PROPERLY propagated in to all the models.

Also: Is it one DRAWING package or are all the building seperate drawing sets? If its the former, i would have one of the MOdels be "Main" for documentation, and i would annotate the other buildings in the other models, and then use By Linked View to get it all in to "one set of drawings" in the documentation file.

If theyre all getting submitted as seperate packages, obviously just do them all seperately...

[dominicsy]

Sep Building = Sep. model. Don't combined them in my opinion. Assign someone to oversee the transfer of assemblies from one model to the others. Use schedules(walls, roofs, floors and ceilings, etc) to see if you have "non-standard" types and replace them as needed.

You will still want to enable worksets.

So you will have 1 site model, 1 building model(worksets for core and shell and interiors) for each building. Note when linking into the site model only link the core and shell workset.


100% agree with Scott.

Each building is a seperate model. Someone will have to manage the content, to make sure when families get updated / walls get updated / materials get updated, that it gets PROPERLY propagated in to all the models.

Also: Is it one DRAWING package or are all the building seperate drawing sets? If its the former, i would have one of the MOdels be "Main" for documentation, and i would annotate the other buildings in the other models, and then use By Linked View to get it all in to "one set of drawings" in the documentation file.

If theyre all getting submitted as seperate packages, obviously just do them all seperately...

Thanks guys. I will start experimenting with managing the assemblies, families and materials between files to see how they behave. The thing about the separate drawing packages is a good point for keeping the building models separate.

I think that having the ability to just "turn on" the building shells in the site file will help us so much for rendering and general slowness.

What would you say are the downsides to merging the entire campus project into one file? Thinking about doing it seems like a good idea, but just gives me a bad feeling for some reason, although I can't really think of a reason why.

[twiceroadsfool]

Well, the drawing package thing is rather large, since you have to decide if each project is getting documented in sets within each model as a standalone- which has a unique set of issues like using the same detailing)- or as one composite project- at which point you should familiarize yourself INTIMATELY with Linked Views, and what that means.

As fasr as bringing content over, i do a lot of it with Model Groups. Saving them out, and loading them in. Be careful with anything that has a definition based on a Profile (like a sweep). The new sweep will come over, the New Profile may not.

Badness about shoving it all in one giant file?

1. It WILL get slow. Not necessarily unmanageable slow, but SlowER. Let me ask you this, whats the GOOD about putting it all in one file? Working in seperate files, you only have to deal with what is in close proximity, and the rest isnt getting tossed around as baggage. A 300 MB file takes a little while to get opened, or to get things to happen, even with 90% of the worksets turned off.

Ive done large campus projects that way, and ive done them with Links. No way id ever go back. But some people hate the Link mentality, and swear by the other method too. Its sort of Chevy versus Ford, except in this case Chevy REALLY is better. :)

If theyre multiple drawing packages, then having it all in one file is a massive nightmare, since you cant use the same sheet numbersin one project file. Unless you Phase number every sheet like the NCS, this will be annoying. (You cant have two Sheet A101's, which makes sense...).

[kreed]

One question to think about is how big are your buildings. Before we really knew what we were doing we had a pilot project that ran in the 275-300 MB range and it was a single building. It really should have been broken up into smaller pieces, but when you're still enamored with all the things Revit can do the single file approach sounds great. Plan ahead if you have large buildings - make sure you have an exit strategy for where to split the building up if it gets slow around mid-DD. It only gets worse once you get to CD's.

Since that project we have used linked files extensively. We're on our sixth campus type project and have a fairly good system down. Linked files really are the way to go for a campus type of project. Search through Aaron's posts on linked files, he's really got a handle on things.

It doesn't sound like you will have to worry about ou major concern, but I'd like to ask a related question: how many linked files can Revit realistically have?
We're up to 35 building links in one master file and it's pretty slow but it's great to be able to show such a large site and it's context. Each building has anywhere from 2-4 linked units inside of it so if you are counting those we're up over 200 links.

Anyone have any experience with that type of project?

[bregnier]

For me, the primary issue with doing it as one file is in moving the buildings after the fact. Keeping them in all one file would really work if everything was on a completely flat site and had the same project orientation. Is this the case? Even if there's a 6" difference between ground floor levels you're better off using linked files, in case the civil plan changes and you have to slightly relocate one of the buildings.

Separate building files also allows you to have the shared base point reference the civil file and each project to have an individual project base that actually references some point on the building. This is _extremely_ helpful when working with consultant revit or autocad files.

In projects with linked units we've never linked the units themselves into the site file, just the core & shell, which helps keep the complexity down.

[twiceroadsfool]

If theres any chance of Buildings moving at ALL, do it as Linked Files. Picking up a building, replete with all detailing, views, detail components, etc, REALLY stinks. Id much rather grab a link and move it. Then all the detailing (thats in the building) stays int he building, and you just have to move the "Master views" in the master documentation file to correlate.

[dominicsy]

Thanks everybody. It's really helpful to hear about issues you all have dealt with that I haven't even thought about. We're going to stick with the linked files.