One Model - All Disciplines

[alaughlin756641]

I don't find a similar thread, so forgive me if this topic has been discussed in these forums already.

We would like to try maintaining just one, multi-disciplinary Revit model. The main Revit model would be built in Revit Architecture 2012, for example. Then Revit Structure 2012 and Revit MEP 2012, would access that model, simultaneously with all disciplines.

Would there be any conflicts in taking this approach? Does anyone see a problem with this approach?

Thank you for your insights.

[renogreen]

After reading your post a couple of times, I'm not real sure I get it. Are you suggesting that the consultants work in the architectural model?

The intent with collaboration is that all the disciplines work in their models and link their models back into each others model to collaborate. Not sure what you are suggesting that is different from that.

[cdatechguy]

Your main roadblock for a one model scenario is going to be network access. If all disciplines were under the same roof there wouldn't be a problem.

[violet78]

I have heard that some people have tried having only one model with everyone working in it, although I have not tried it. I see some issues. The biggest, where does the central file live? Is everyone in the same office or will you need to host it somewhere in the "cloud"? You will have to maintain strict rules about who controls what - you don't want engineers to have control over moving walls since they may not see or coordinate all the results. Dividing everything into worksets will probably be your best bet. Also, with all that info in one place the file will get very large very quickly.

[david_peterson]

It's doable depending on the size of the project. You'll need some real beefy workstations or an ultra fast network and a cloud set-up. Either way, a lot of hardware may be required unless you like to spend more time drinking coffee than doing work.
I'm not sure I'd want to go that route, but to each their own.
Some of the potential problems I could see you running into is someone overstepping their bounds. "Well I moved the toilet, so I thought I'd just re-work your plumbing for you while I was at it. One way to insure this doesn't happen would be to simply have the plumbing drafter (assuming there's only going to be one) check out all of his worksets or put all of his/her stuff on that workset and leave it checked out.
I had a sim thing happen to me in the acad days. I sent our consultant our new grid layout which included our shear walls and braced frames. When I got the arch update back, my shear walls were in different spots and a few grids were now moved. The Architect thought they knew better than my engineer.
Now again if you're all in the same house, it should be a little easier to control since you can always walk over to that persons desk and slap them upside the head if need be.;)

[Steve_Stafford]

As David wrote...doable but it depends a lot on circumstances.

The first...is everyone in the same firm and does the network support the strategy. Stop right there if it isn't/doesn't.

Next is project scope. Is it "too big" to have all the trades in one model and not drive everyone batty waiting for things to happen? Once a team get to be larger than 8-10 people anecdotal evidence suggests that performance suffering becomes more noticeable. Kind of like the reports that say people begin to notice network latency when it gets worse than 100ms (perception of slowness/sluggish network).

Another is the "deliverable". One client gave it the old college try with one model and really liked the high degree of interaction. They hated plot day though because a certain discipline "never stops designing". It's a lot easier to freeze a design for plot day when the trades are in separate models.

Another client gave in early when they realized this at the first submission. The other one I mentioned stuck it out throughout, but they admitted plenty of stress. The project also wasn't very large, three stories, don't recall total area though.

Keep in mind this means a substantially more involved template that doesn't really exist "out of the box". You've got to merge all the engineering stuff into the arch/struc or do the reverse. But it's all got to be available otherwise somebody will be asking why "x" doesn't work. It'll keep you hopping! :)

[alaughlin756641]

Thanks for all this input. I should have said, all disciplines are under one roof, one network. Good workstations. We see more performance problems with linked models, than working in one model.

I was wonder more specifically if the databases are in any way different. Would there be potential conflict with the way objects are identified in Architectural vs Structural. Are the unique ids for each object handled identically between the apps. Assuming so.

We believe we can work much faster from one model, than the management overhead of linked models, copy/monitor, etc.

Great replies. Thanks.

[david_peterson]

From the little bit I know, there's no real difference.
You should be able to have someone working in RS or RMEP open the composite model in RS or RMEP regardless of which one was used to create it.
However, Structure (I believe) needs to use RS and MEP needs to use MEP to complete their work inside the Arch database so that the families are properly created. ie arch walls are different that structural walls.
I don't think revit cares what program you open it with. All the data should still be there. The only other thing to think about is working in a file with 1000+ sheets and many more families. It's just a lot of stuff you'd have to sift through.

[cdatechguy]

I'm currently working on a 2012 template for both our structural and architectural to work in the same model. What we plan on doing is creating an already workshared project so that we can get all filters, view templates, project browser...etc..etc.. already setup before working on the actual project.

We have always linked in the structural model, even though we are on the same network. So this will be our first attempt at one model. ;)

[Steve_Stafford]

Sharing the same model will increase the number of warnings. In particular you'll see the RME system related warnings pile up if they don't bother to define systems or leave things disconnected for awhile. You'll need to stay on top of it or you'll end up with big numbers!

View templates and Filters, better start working on them now, there will be a lot.

[alaughlin756641]

Thanks, Steve.

We will initially just have Arch and Struct in the same model. View Templates and Filters are strategies that we use, but always there are exceptions, adaptions and new strategies. This is never complete it seems.

We are looking for ways to reduce what turns out to be a lot of redundant and inefficient work. Another strategy we are trying is to train the Arch side to use the MEP / Struct models for those components they are responsible for: Columns, Lighting, Roof Design, etc. Copy/Monitor tools are problematic even when things are working well. The goal is to put the right element in the right place once, no more Copy/Monitor.

Good thought on the warnings. That would be difficult to manage. The model may get too big, we realize.

[RobG]

"We see more performance problems with linked models, than working in one model. "

that to me raises eyebrows. if you're having issues with the linked models, then having it all in one and creating a massive model with more-then-usual number of users in it at one time sounds like it'll cause bottleneck issues.

unless i'm missing something.

Cloud computing, in the long term, will change a lot of that in my opinion. While I think it's nice to say it's being a leader at something, I don't know if this is the one where I'd want to be the guinea pig!

[alaughlin756641]

A more careful wording on my part, I think, would have made this better understood.

By performance, I meant the overall efficiency and speed at producing construction documents, not the performance of Revit on a workstation. Macro Vision = Revit linked models is better individual response than one larger model on a specific workstation.

"One model" experiment is an effort to rethink and address the Long View that there are significant work flow ineffiencies with a linked model by discipline, Copy/Monitor approach. Disciplines really do cross each other; lighting is an area that is particularly bogged down with Copy/Monitor. If we could place lights once and they addressed the requirements for both Arch and MEP without duplication, the productivity improvements would be significant and may offset the complexities of managing a single model.

At this stage we have not integrated a project into a single model but are beginning to experiment, so I thought I'd query and see if there were any technical obstacles.

[cdatechguy]

Our obstacle is the structural department and architectural setup their Revit projects differently...even though we are under the same roof. So trying to setup a template that merges these two thought processes is proving very interesting. For one structural uses black lines....architectural color...I know I am gonna get yelled at for going to black lines ;)
But since it seems most folk just want the color lines for detailing/drafting views (so its like working Autocad) so I plan on creating a view template for colored lines in those views.

Speaking of views....we are gonna have to come up with a strategy for the project browser based on discipline. Figure on our last project just on the architectural side we had 1270 views for one model.

[Steve_Stafford]

My earlier replies make it sound like Revit and technology are the primary hurdle to getting this to work. The real tricky part is what a few have said here...people and how we work and do what we do. Merging everyone together in separate .dwg and agreeing on layer standards is one thing. Actually trying to work together in the same virtual model...madness ;) Why that's like...um... a construction site! :shock:

One interesting pairing I've also seen is Arch/Elec. Both share a lot of stuff and merging them together can reduce the "my light" versus "your light" to just "our light".

[cdatechguy]

One interesting pairing I've also seen is Arch/Elec. Both share a lot of stuff and merging them together can reduce the "my light" versus "your light" to just "our light".

And the moving of ceilings....or deleting...

[Damo]

One interesting pairing I've also seen is Arch/Elec. Both share a lot of stuff and merging them together can reduce the "my light" versus "your light" to just "our light".Hi Steve,

On a like-for-like basis (or should that be light-for-light;)) is the "my light" in RArchitecture the exact same family as "your light" in MEP"?

If they are, and there seems to be more light & electrical fittings in MEP than in RA, can I just copy those MEP electrical fittings that I find useful into my RArch template?

[Steve_Stafford]

Technical yes. The trouble that Architects have with the RME fixtures is that they are more specific about usage based on the voltage distribution. The other issue is they may not match their symbol expectations. Then again does any of the content do that? :)

Do you want to have to choose a 4 - lamp 277 volt fluorescent fixture or a 2 - lamp 120/208 version? Often the architect doesn't "care" about that, they are more interesting in placement, at first anyway.

[Damo]

Thanks Steve,


The other issue is they may not match their symbol expectations. Then again does any of the content do that? :)Indeed! Severe lack of UK Electrical symbology here

[cliff collins]

Copy/Monitor, anyone?

Has it's advantages and disadvantages---but the Arch/MEP coordination/collaboration problem
can be somewhat solved using face-based lighting and plumbing fixture families, and Copy/Monitor.

cheers

[alaughlin756641]

Steve is on the mark with the lighting example. Architect cares about the fixture style, Electrical needs lamps and voltage. Here we are starting to use a super-family concept of one light fixture type, eg. linear recessed (face based). We will have just a handful of lighting fixture families - 10 at the most. This is setup with a base that meets all of electrical needs, then there is a nested series of families inside that are the architect's "fixture style" and can be selected inside of the electrical type by the architectual side.

This is starting to look like it will work really well. So with that solved, we still are not getting good construction document work flow with Copy/Monitor. Another big benefit with this approach, is that the models can become much lighter, so performance improves. It's also much easier for someone to choose from 10 lighting fixtures, than hundreds.

C/M is primitive and solves Revit problems when it is working well, but it does not really support BIM ideals and, more importantly, it is causing a lot of rework and errors that we want to evolve beyond in a multi-disciplinary work flow. If we are truly forward thinking and evolving Revit as a BIM solution, IMHO copy/monitor is archaic.

Which brings us back to the original query, using the example above, would we have technical problems if the architect placed this super style lighting family, then the Electrical engineer used the MEP app to open tha master model and set and schedule the electrical data from the same model.

Sorry to be long winded. I'm passionate about moving Revit forward, it is a great product, but we can't stop here and captiulate because that is what a white paper said is best practice four years ago. Can we?

[alaughlin756641]

Another thought for the pot. These discussions have me thinking about my own query.

Maybe the one model concept is not just one model, but it is a master model for all information that is shared by disciplines. Anything that we have needed to C/M.

Mechanical duct -- never shared -- it stays in its own model. Lighting -- always shared -- it is placed in master model and both the Architect and Electrical Eng access it with their respective Revit apps.

Structural would always be in the master model.

[mrauscher]

I've worked on several projects with this approach. It works, but our consultants have issues with network connections and their saves to the central file hold up the rest of the team.
We host the central file on a server that the consultants have access to through Riverbed.

I recently finished a project which was quite small, but included a lot of detailed information. We didn't have issues with worksharing so long as each consultant had their own worksets to use (typically STRUC_New Construction, STRUC_Reference Levels and Grids etc).

I wouldn't recommend this approach with a large project. Unless everyone is under the same roof (as stated by others), it would be difficult to achieve the network access that wouldn't slow people down during Syncs to Central.

Also, the need to impliment a BIM Element Ownership Matrix is imperrative. This sets the ground rules for who controls what part of the model. Without strict ownership control, you risk elements being modified by the wrong team without knowing.
Good communication at all times is also a major plus. :)

[cliff collins]

Revit Server and AEC Vault are some other avenues for collaboration with muti-office/multi-discipline projects.

cheers

[mthurnauer]

I am working on a project that has the arch and structural in the same model and we are in separate pffices and using Revit Server. It has worked pretty well. We have occasionally has some issues of getting warnings that "my local cannot reconcile differences with central" of " the central files is busy", but this does not happen often. I also realize that even though the project is decent size, the team is very small so we don't bump into each other very often.

[Damo]

Technical yes. The trouble that Architects have with the RME fixtures is that they are more specific about usage based on the voltage distribution. The other issue is they may not match their symbol expectations. Then again does any of the content do that? :)

Do you want to have to choose a 4 - lamp 277 volt fluorescent fixture or a 2 - lamp 120/208 version? Often the architect doesn't "care" about that, they are more interesting in placement, at first anyway.Trying to solve another problem with placement of light fittings in MEP, I loaded some RAC light fittings into MEP. However these seem to behave differently as I lose the choice to 'Place on Face' and 'Place on Work Plane'.

[Steve_Stafford]

Most, if not all, RAC fixtures are ceiling hosted... :(

[ksmith.207733]

I work for a firm that is somewhat progressive for our area. We want to create on complete BIM model as well we are working towards using Revit Server. Im a little intimadated by the administrative tasks that seem to be nessasary in order to use Revit Server since I will most likely be the person to perform these tasks. Can anyone point me in a direction for Revit Server guidelines (other than WikiHelp)? Im also curious how do you manage the workflow? obviously several worksts will have to be established, but whos to say that we wont be moving each other's elements?
As for the light fixture scenario Ive decided to work with our MEP engineers in creating light fixture families that can be used to for both disiplines as long as the light fixture has the correct size and general shape that we are looking for on our RCPs we will be fine. Then we can incorporate the symbols that they use for thier lighting plans that can be toggled on and off easily within the family. In theroy it seems like it could work but Im not sure that it will in reality. Any tips on using Revit server or resources would be greatly appreciated.

[Craig_L]

I've written some pretty descriptive posts on this in the past, I can't seem to track any down but if you do a search you could probably find some of them.
I'll try to keep this short, as from memory I did long descriptions in the past for this topic...
As with all methods and workflows, there are pros and cons I believe that all disciplines in one model has more cons however, than pros. Just so you understand, I am talking from experience, I worked on a project with Arch/Struct/Mech/Elec all in one model. It was, to put it mildly, a nightmare.

Pros:
-No need to co-ordinate models, reducing time in mismatched models and problems when or if the project needs to be relocated.
-1 model means less file space and easier management /purging/ cleaning and auditing

Cons:
-Changes done by each discipline affect each other discipline. This means you need extensively thought out and refined view templates, very disciplined modellers who assign the correct discipline to every item they place (or a good designer who has programmed your families to do this automatically)

- Changes done last minute near an important issue can cause MAJOR follow on problems for the other disciplines. You can not expect (for example) your structures team to be able to update their documentation to match the architects changes to a slab in a short amount of time. You need to leave appropriate lead times and hand over times of important changes, and milestone issues.

-The single file tends to be enormous.

-If the file corrupts, you hold up 4 disciplines, instead of 1 while you have it corrected by Autodesk.
This means downtime for potentially 4 times as many people.


The list goes on for the cons, but those are some of the major ones.

In my opinion, and experience it's far far easier to manage linking in several outside sources, than it is working in a multi-discipline model.

[JPDOMEIN]

Hi, we have been working in shared models for the last year and a half. Usually the models are about 200 to 250 mb., just touching the max. file size advised. One of our partners currently is working with a 500mb model, this is sluggish. Checking this model we noticed a huge amount of groups, nested groups, etc. Massive use of Ref.planes. Very little (about five) worksets. Wrong setup.

We noticed during working in shared projects that it's more than just 'add walls' or ' I do my stuff '. When working in a BIM surrounding (note: not just a model) communication and trust is a must.
If you don't communicate (phone, email, in the model): it fails.
If there is no trust: it fails.
Architects don't touch structural stuff and vice versa. If you see something that isn't correct: communicate!! Use Navisworks or Solibri to compare/clash control models on a daily / weekly base. BIM is more than just working in a 3D model, much more. BIM is the entire proces. BIM is a way of thinking. Bim is .....

We're using Globalscape WAFS and noticed that whenever errors occur, it's for 99% user related.
Like above: wrong setup of model, not familiar enough with Revit, too much CAD thinking, etc.

If you are about to go with shared models, rethink the way you used to work.

[ksmith.207733]

We have already started a model on the Architectural side. MEP and Structure have not. Our MEP team is very accoustomed to using worksets because they have to break thier model into several parts in order to work in one model. Our structural will just be one person, therefore Ive thought about asking him to maybe set up worksets so that they will help us (architecturally) control visibility of elements. For example, one for structural framing, one for columns, and one for slabs and footings. Ive also thought about asking MEP in addition to the worksets that they normally use taking light fixtures and grilles and registers to thier own individual worksets for the same purpose to help us control the visiblity of those elements in our drawings. We are trying to think this out as much as possible before we dive into it. I dont think that turing back to linking is an option (my boss is pretty set on this) The main issue Im having is our MEP team has everything set up in a way that nothing is ever hosted. I guess because they say that is they host something and we move the element that it's hosted to, thier element gets thown into space Once they re-link our model. Well on the most recent project we sent out we ended up with a terrible BIM model every light fixture was at the wrong height, every light switch was at 0 elevation. It completely defeted the pourpose of BIM and we are hoping that one model will reduce these issues???? Any thoughts?? Thanks again.

[JPDOMEIN]

Use much worksets but don't overdo it. :mrgreen:
Usually we advise: divide the building vertically (expansion joints) and/or horizontally (levels).
If this is done for each discipline (arch, cons, mep) you get an pretty clear model.
Naming is important. Example:Discipline/company_vert_hor could look like this:
MEP_block1_level4.
So its easy to see who's workset it is.

Make sure people are working IN the worksets to avoid Revit trouble like central file is busy.

Hosting of elements is a problem, Autodesk really needs to work on that.

just some thoughts.