Revit and IFC, Part I

March 21st, 2011  |  Published in Revit, Work  |  2 Comments

BACKGROUND

Currently we have a major State project that is in collaboration with another Architecture firm that uses ArchiCAD. We’re running Revit Architecture 2010 (our project model has been in-process since 2009) and the rest of the consultants are using their respective Revit flavors or versions of AutoCAD. The intent of the project is to be fully “BIM” with the Construction Manager using the design team’s models for coordination and collision detection.

THE PROBLEM

Revit and ArchiCAD do not share file formats and are fundamentally different; in order to meet the client’s standards for a BIM project we need to use IFC exports to exchange datasets between the two platforms…herein lies the problem and the source of not a few of my recent grey hairs. What follows is my experience translating the ArchiCAD model into a usable format for the entire non-ArchiCAD design team. These are my lessons learned and insights regarding this specific model; others hopefully have different experiences with IFC translation. This post is meant to spark a dialog amongst users so that the process can become more smooth and accurate.

FIRST STEPS

When working in collaboration with an ArchiCAD firm; and before starting your Revit model, setup a meeting to discuss the basic (model) layout for the project. Specifically relevant to IFC translation are the levels, cut planes and project origin that will be used in the models.

When linking a model in Revit, the linked model’s levels do not affect or get affected by the host model’s levels–ArchiCAD does not handle levels in this way. Any level in a linked model within ArchiCAD will be matched to the host file’s levels, in order and not by elevation from the origin. This means that if you create mezzanine levels between floors (that the ArchiCAD model does not have) the mezzanine levels will be shifted to the next host file level. This ends up “exploding” the linked model within ArchiCAD and the only way to fix this is to add the extra levels in ArchiCAD or remodel in Revit (deleting the “extra” levels and re-hosting objects).

When dealing with (plan/RCP) cut planes; Revit has more options than ArchiCAD via the view range settings and the plan region tool. Work with the ArchiCAD team to determine where their cut planes occur as these will most likely need to be tweaked once their IFC is imported into Revit.

When dealing with the origin–use 0,0,0 and do not move the project base-point in Revit. ArchiCAD does not allow the user to move the origin so any deviation from the pre-set origin could be problematic. If both teams base their respective models on the default origin, file imports both ways will be much smoother (import origin to origin) and not require any guesswork or reliance on grid lines that may not make it through the IFC translation (most likely they won’t make it)

IFC ISSUES

The IFC file format has some fundamental flaws when used in a BIM workflow; namely it lacks instance support and phasing support. Walls and floors (if modeled cleanly) will usually come in as instances of a wall type, but elements such as light fixtures will import as individual objects. Phasing information (existing construction, demo, new construction) is lost and any imported object will take on the phase of the Revit template file used. The phasing issue is compounded due to Revit’s and ArchiCAD’s differing methods of handling this information. Revit uses an actual phase (existing, demo, new) property for each object whereas ArchiCAD uses a layer (similar to AutoCAD’s methodology).

BRINGING IT INTO REVIT

If you are working on a project that is entirely new construction, the phasing issue is not a problem as everything is the same phase. Our project; however, is an existing building with a new addition. The workaround for the lack of phasing support that I came up with was having the ArchiCAD team export three separate IFC models: one for existing construction to remain; one for demolition and another for the new construction. I imported the three models individually into Revit and had to manually combine them into a single model that could be linked to our model. This is where my trouble really began.

The images below illustrate a major issue that is the result of the combination of poor model management (by the ArchiCAD team) and the IFC translation process that occurs when trying to combine multiple IFC files together. Look at the names of the floor types in the first image and the wall types in the second.

Truncated Names

Blank Names

If the original object names are long or happen to have been modeled on an incorrect/inaccurate layer in ArchiCAD the type name will get truncated, or there won’t be a name at all. As a result, many objects (as shown in the images, right) will have the same name. This only becomes a problem when merging the phase-separated files as objects coming in will take on the properties of similarly named objects already in the phase-combined model. I learned this the hard way when I was copying and pasting elements into the combined file (this probably explains why the link-bind method failed).

I didn’t notice this issue (7″ slabs all of a sudden were 12″, etc.) until I was too far along to undo the copy-paste and had to start over from scratch. I ended up manually re-naming nearly every object/family. This isn’t an ideal solution as I had a very limited time to create the model translation and had to use names that are less explicit than I would have liked. The re-naming was made more difficult because some of the object types apparently had “local” parameters modified to change their materials so that the displayed better in the ArchiCAD views (see the image below).

Background Fill

The background fill material is apparently how ArchiCAD creates a “hidden-line” view of cut objects, unfortunately, it is no help in determining what material the object is supposed to be when exported/imported via IFC (see image at right).

Another issue that I came across is purely because of the method employed by the ArchiCAD team when modeling. In ArchiCAD (I’m basing this on a conversation I had with my counterpart) it is possible to change type properties of a wall on a per instance basis without needing to create a new wall type (this is akin to changing the color of a line in AutoCAD via properties instead of creating a new layer with the desired color). Modeling standards/methodologies aside: ArchiCAD’s IFC exporter doesn’t read these instance properties and instead exports the wall with the type properties. I’m assuming it’s the exporter as Revit is receiving more complicated wall assembly information (as shown in the image below) of other exported walls and floors.

Complex Wall Assembly

Instance Properties Lost

This creates walls (or any object done this way in ArchiCAD) that are the completely wrong type and defeats the purpose of BIM.

I ask all of you reading this (Revit, ArchiCAD, Rhino, MicroStation, etc. users) to please model cleanly and use explicit (but short) names whenever possible. Taking shortcuts may work well in the moment but they usually cause problems later on, especially if someone else needs to use your model. The IFC process takes an already bad model, makes it worse and nearly unusable.

The next part in this article will discuss additional issues that arise during the IFC process and other quirks related to ArchiCAD’s workflow (they don’t have a ceiling or a ramp tool!)

Responses

  1. Nick Nisbet says:

    March 24th, 2011at 7:32 am(#)

    <> No it doesn’t. What has been lacking is user pressure on Autodesk and Graphisoft to implement the facilities in IFC. ‘instance support’, by which I think you mean transmitting Library/Common/Family/Type objects, is ubiquitous throughout IFC. Phasing is outside of the agreed ‘Coordination View’ but look at Synchro (for example) and tell me IFC doesnt support phasing.

    A similar article could be written from the point of view of an ArchiCAD user receiving IFC from revit. They might mention the duplication or omission of Type names..

  2. rehiggins says:

    March 24th, 2011at 8:21 am(#)

    You’re right–a similar article can (and should) be written from an ArchiCAD point of view. I know that the typical method of working in Revit can cause problems in ArchiCAD and vice versa (which is the point of this article). The majority of problems that I’ve been running into are due to how the ArchiCAD team has decided to model, not necessarily an ArchiCAD or IFC problem (hence the comment regarding an already bad model). When the objects are modeled cleanly, IFC translates the information properly. The instance issue typically occurs when objects such as lights (or doors or furniture) are involved. Instead of being exported and imported as an instance of a type (library element); where changing the properties of one propagates out to all, they come in as separate elements each with their own type properties. This becomes a huge hassle when a door comes in with the wrong plan symbol (double doors coming in as one large single panel) as the typical method of working in Revit no longer works (modifying the family [library]) since the doors are individual types even though they should be the same. This is clearly a failure of both programs’ IFC implementation.
    Users do need to put more pressure on the companies to better support IFC (if IFC is going to be the dxf of the BIM world). I know that IFC is on the back-burner because it is seen as something only used in the academic world and not really implemented in real-world settings. This is obviously not true.