Revit User's Manual/Interdisciplinary Coordination

From Wikibooks, open books for an open world
< Revit User's Manual
Jump to: navigation, search

Under Development - Come back soon for completed content

There are three distinct products in the Revit platform, each focused at a specific discipline:

  • Revit Building – Architectural Design
  • Revit Structure – Structural Design
  • Revit Systems – Mechanical Electrical and Plumbing/Piping Design

It should be noted that effective Revit Collaboration is based on two parameters, the Platform Version and the Product Build.

For efficient and effective collaboration as we will demonstrate in this example, each partner MUST be on the same platform version of Revit. These platform versions are dictated and best referred to by the version of Revit Building that they correspond to. The most recent platform versions would be:

Revit Building 8 Revit Structure 1 N.A.
Revit Building 8.1 Revit Structure 2 N.A.
Revit Building 9 Revit Structure 3 Revit Systems 1
Revit Building 9.1 Revit Structure 4 Revit Systems 1.1¹
Revit Systems 2¹


¹ For the Revit 9.1 platform there are two compatible releases of Revit Systems. Revit Systems 1.1 refers specifically to the compatibility release of Revit Systems that was to synchronize with Revit Building 9.1 and Revit Structure 4. This is not an official “branded” release of Revit Systems, but does refer to a specific build of Revit Systems 1.1 (build 20060810_2300). Revit Systems 2 is branded specifically as such and should be easily identifiable.

Product Builds[edit]

It is recommended that within each product, all people collaborating be on the same build. Identifying what build you are using is very simple. Go to the Help menu and select Product and License Information. You will see a dialog box like this with the version and build information:

RevitProductBuild.jpg

Note: Within the same firm, it is required that all people working on the same project using work sharing be on the same build. Different builds can cause Save to Central issues

Workflow Scenarios[edit]

There are several possible workflow scenarios that might exist in a project. For the purposes of this example, we will speak specifically to the workflow between the traditional design team consisting of:

  • Architect
  • Structural Engineer
  • Mechanical, Electrical, and Plumbing/Piping Engineers.

If we were to graph the traditional workflow between these disciplines, we would see something like this: Collaboration-scenario1.jpg

What this diagram illustrates is that the workflow in a typical design team is very complex. There are primary relationships (architectural to/from structural, architect to MEP) and secondary relationships (structural to/from mechanical and piping).

In addition, these relationships also can be further broken into physical and logical relationships. If we use mechanical and electrical as an example, we can see that making sure that a light fixture is not hitting the bottom of a duct is a physical relationship, while making sure that the electrical design properly accounts for the load of the heating coil in a VAV Box (being designed by the mechanical engineer) is a logical relationship.

It is the complexity of these possible workflow scenarios that makes this process prone to errors and a major source of coordination between the traditional design team. So what are the tools that can be used for collaboration between Revit products? There are three distinct tools that typically are used in a collaboration scenario:

1) Linked Models

Linking models together using the Revit link tools provides full visual fidelity to see what the other disciplines are doing. The important thing to understand is that this simple process provides the following benefits:

  • Full 3D visual fidelity – The linked model will show the complete context of the other discipline’s data allowing complete understanding of their geometry.
  • Visual Control – The data in the linked model can be controlled and shown in any manner appropriate to the use. You can turn it on or off, half-tone the data, or enhance it with color or linetype.
  • Support for Interference Check and Coordination Monitor – The next two tools all build on the platform of linked models and would not work without this base tool.

2) Interference Checking

In many cases, the only workflow requirement is to know that items from another discipline are not interfering with your items. Interference checking can be a very significant tool for these reasons:

  • Multiple Uses – You can interference check between categories within a single model or between linked models.
  • Sufficiency – In many cases, the primary workflow is to know that things are not in interference with each other.
  • Low Overhead – Since interference checking is something that is run completely “On Demand” it has lower impact on performance and system requirements.

3) Coordination Monitor

The coordination monitor is a very powerful tool in the Revit platform. Considered the most “intelligent” of the coordination tools, coordination monitor offers these benefits:

  • Intelligent Bond – Using the coordination monitor, you can chose items from another model that you want to monitor for change, and the degree to which you want to monitor them.
  • Multiple Modes – Often misunderstood, many people do not realize that there are two modes of coordination monitor – monitor only and copy/monitor. Using the correct mode can allow additional functionality flexibility.
  • Geometry Creation – When used in the copy/monitor mode, you can actually create geometry from the linked file into the source file. In this mode, you will also be establishing a monitor relationship similar to above.

These are the tools available to you. When to use each of these scenarios depends on the workflow requirements between the disciplines

Structuring your Project[edit]

Understanding the tools that are available leads to this topic, how to structure your models. Should we model in a single file? Or, separate the models based on discipline or another concern? There is one simple rule for how a model might be structured, the transmittal.

Think about that for a little bit, a transmittal is the means that you use to formally tell someone that there have been updates that they should respond to. A transmittal might be a formal transmittal; it might be an email, or maybe something as simple as a post-it note on a CD. However they are used, it is a good idea to separate your model(s) based on this simple thought.

If this is something that you would notify another member of the team that there have been updates using any form of a “transmittal”, then it should be in a separate model.

It is recommended that each discipline work in a separate model, and that they provide these models to the others on the team for collaboration. There has to be a hard deliverable point when the structural group responds to the changes in the architectural model, mechanical responds to architecture and structure, etc. etc.

Workflow Application[edit]

Now that we understand the potential workflows, the tools, and recommendations on how to separate our model(s), we are ready to start setting up collaboration on a project. What tool each discipline uses is based primarily on the requirement of each discipline from the others.

Collaboration-scenario2.jpg

This diagram represents suggestions for collaboration tools to be used between the disciplines.

Architect - Structural Engineer

The relationship between the architect and structural engineer is becoming closer and closer as we strive for lighter structures and more innovative design. In many respects, structural engineers may be shaping the envelope as much as the architects. As such, this workflow may be considered the most crucial and should be bi-directional.

Architect to Structural Engineer – Coordination Monitor

By using the coordination monitor, the structural engineer is able to create a strong, intelligent link between the structural and architectural models. In doing so, he can easily track the changes in the architects model that will affect the structural design. He is also able to create geometry in his model using these tools, moving well down the path to having a structural model.

Structural Engineer to Architect – Interference Checking

The architect’s requirement for the structural model is primarily to have the structure in context, and to know if the structure is interfering with the architectural elements. For this workflow, it is recommended that the architect link in the structural model and use interference checking.

Architect – MEP Engineer

The relationship between architecture and MEP is not quite as dynamic as architecture/structure, but represents specific opportunities to benefit from collaboration.

Architect to MEP Engineer(s) – Coordination Monitor

The MEP Engineer needs to link in the architect’s model to have the architectural model for context and positional relationships for ceiling based items, and to avoid clashes. The Coordination monitor is used to copy/monitor in primarily the architects levels and rooms. These room objects take on the additional properties of the MEP model when copied in, properties such as light levels and air flow. Levels are required to copy/monitor the rooms.

MEP Engineer(s) to Architects – Linked Models

The architect’s primary benefit from linking in the MEP model(s) is the ability to reference this geometry to show context in architectural drawings. There is not typically a strong need or benefit to using coordination monitor from MEP back to architecture.

Structural to MEP Engineer(s)

This relationship is almost always best served by cross linked models using interference checking. The most important aspect of collaboration between these disciplines is the early detection and correction of clashes.