IFC Translator to Revit - lots of problems

[Anonymous]

I'd be interested in talking to anyone that's had any success in sharing models between Archicad and Revit using the IFC format. Please please please PM me if you have done this successfully.

Currently we have a myriad of issues, and likely more I am not fully aware of. Our Structural and MEP consultants cannot use our model in theirs, and this is a major problem. Likewise, we have very limited control over the structural model that we get, as well.

1. Walls (and probably other objects) are missing entirely from the model, once it gets converted and imported into Revit. Seems fine on our end, looking at Solibri. Even looks ok on their end as an IFC, but once converted to Revit, they lose data. Revit IFC add-on issue...

2. Walls get assigned a unique ID in Revit - this evidently changes every single time we send a new model and they import it. As a result, nothing in the MEP model can be hosted to our walls, making our model essentially worthless to them. Every time they get a new model from us, anything wall-hosted loses its ID and host.

3. According to the MEP guys, pretty much all of our model gets put into the "generic model" category in Revit, making it impossible to filter our elements in their views.

Like I said, these are only the major issues I know about, but I am sure there are more. I'd be very very interested in talking to anyone that successfully shares data between consultants using these two softwares.

[Ransom Ratcliff]

Dan,

I'll contact you offline to see how we can improve the exchange.
But let me also respond here on a few points just for the benefit of anyone else reading this post. A book could be written on this topic, so this post will be both much too long and much too short.

Using IFC as a stepping-stone between ArchiCAD and Revit presents great challenges because of the great differences between their underlying technologies and the logic they employ to convert human intent into deliverables. As BIM authoring tools, they are fundamentally different from Solibri, Tekla, or Navisworks.
In order to make a sound business judgment about how (or whether) to use IFC in a collaborative workflow, you need to start with an honest understanding of what can efficiently translate into IFC from one tool and come out in the other tool. This is a bi-directional question and it is even more challenging for content that needs to make a round trip, rather than content on either end that only needs to cross one time. For round-trip content, simply editing some of that content second application, adds yet more friction.

So let's start with what IFC exchange will not achieve between ArchiCAD and Revit. If that turns out to be unacceptable, then we can use other techniques and workflows to supplement IFC, or supplant it.

A good basic contract-deliverable production-BIM in Revit or ArchiCAD cannot be authored in the other application. Indeed, even staying on the same platform with Revit Architecture and Revit MEP, has serious workflow challenges that surprise people who have not run such a project in Revit.

You mention in your second point that the MEP engineers cannot host their fixtures on walls authored by the architects. But surprisingly, in Revit this is not a practical workflow anyway unless both teams work in the same model. And if the teams are on different Local Area Networks, working in the same model is more difficult in Revit than programs you may be familiar with such as ArchiCAD, AutoCAD, MS Office, etc.. So in practice, different disciplines typically work in their own models that started with templates optimized for their own needs. I only mention this to make the point that sometimes ArchiCAD users get unfair criticism for their contributions being incorrect or incompatible with other platforms. The truth is that Revit to Revit collaboration is a pain and so if you are getting compared to a Utopia that never actually occurs in Revit, it could be pretty frustrating. In practice, many experienced Revit MEP users have moved towards face based families or even un-hosted families for mounting fixtures "on" elements authored by architects.

So what is IFC good for? That is a moving target as Autodesk and Graphisoft make strides in improving their IFC translation. But so far, my experience with IFC workflows between Revit and ArchiCAD has revealed some criteria that relate to the nature of the content that translates across the chasm. Here is how I divide it up:
1. Native quality editable content. E.g. walls that are editable the way walls in the host application are supposed to be edited. This would include the ability to move, delete and add doors, stretch the wall, connect (join) other walls to it, schedule the imported wall properly along other walls authored in the host application. Ideally, the imported wall would also generate the graphical representation intended by its author. This means that ArchiCAD composite walls would arrive in Revit with the composite layers showing with correct thicknesses and fills in plan and section. We should not forget surface appearance in 3D and elevation.
2. 3D content that is geometrically accurate but has lost its essential quality as natively editable elements. In ArchiCAD, this would be like getting a wall saved as an object. Sure, this object could be called a "wall.gsm" and it could even have a generous serving of metadata attached to it. But no ArchiCAD user would consider it a real ArchiCAD wall, even if it were editable by "morphing" it. Likewise, a wall imported into Revit that gets translated into an "in-place massing" or even an "in-place" wall family, is not a true Revit wall in the way that a Revit user would accept as "best practices".
3. Simple elements such as solid straight walls..
4. Distorted, Missing/lost content.

I mention walls only as an example, but I'm talking about all the other elements, objects, and families in a BIM.

With all this in mind, I have found IFC most useful for 3D coordination. Using the BREP translation, you can get geometry and designation of what that geometry represents, to convey between disciplines so that you can see your model in the context of the other models. This is similar to bringing the models together in Navisworks, but with the advantage of staying in your authoring tool in order to intuitively edit the context of what you see. When 2D graphical representation is important, (which is most of the time) I supplement with DWG backgrounds.

Another tip: ArchiCAD imports IFC content pretty well but it is typical for Revit users to experience extremely long times opening IFC files of any complexity. Aside from the fact that Revit leverages multiple cores rather poorly for the important stuff, it has a special challenge with imported BIM elements; The Revit engine is designed to make the whole BIM parametric, far beyond what ArchiCAD is attempting to do. (BTW, ArchiCAD objects have always been far more parametric than Revit families.) I describe Revit as a "procedural database" while ArchiCAD is "relational database." What this means is that a Revit BIM is very dependent on not just the presence and position of authored elements, but also the order in which elements are authored. Indeed, the order of the authoring process affects the constraints that control the behavior of the model and even the resulting design.
ArchiCAD has few constraints and none that are not deliberately applied by the authors or applied automatically in a way that is obvious and expected. In ArchiCAD, an example of the latter would be that when we place a door in a wall, the door moves with the wall and even adapts its jamb conditions to fit the wall.

With larger IFC imports into Revit, the quantity and variety of elements that suddenly appear in the database without ordering information or constraints, creates a kind of "chaos" that needs to be sorted and categorized in a "procedural database" like Revit. That is why Revit takes even longer to import IFC data than it takes to export it. So, for speed and reliability, it is best to see IFC as a way to convey a part of your design that is relevant for particular decisions or design issues. If the whole building must be converted, you might have better luck saving it out in multiple pieces and reassembling them in Revit in a specific order.
More experimentation needs to be done with this and some can usually be combined, but here is the order I think Revit copes with best, in terms of elements being authored or imported into its database:
1. Levels (ArchiCAD Stories)
2. Grids
3. Columns
4. Load bearing walls
5. Non-loadbearing walls
6. Structural slabs
7. Non-structural floors
8. Ceilings
9. Lighting, Diffusers, floor mounted fixtures, casework, and furniture.
10. Everything else

Site should probably remain in a separate dedicated Revit model.

Also, avoid any content far from the Origin (0,0,0) point. A ten-mile radius from the origin is the maximum and I would stay well short of that if possible.

Lastly, the new add-on for Revit 2015 is improved over the one we had for Revit 2014. Likewise, ArchiCAD 18 is better than ArchiCAD 17 for IFC in and out.

Sorry for the long post.

Ransom

[David Maudlin]

Ransom:

Very informative post, thanks for taking the time to share your experiences from both sides.

David

[Rob]

Dan,

Just some factual comments:
The most common version of IFC that is used currently is 2x3. This version does not explicitly provide full support for parametric element definitions. However the new already certified version 4 does, so there are foundations laid for this kind of information flow already. It is really up to software vendors to pick up the ball, implement the standard and get themselves certified.

Collaboration based on directly shared model is currently utopia not just because of the correct parameter transfer issues but more importantly because of legal and contract procurement issues - simply it needs be clear who is responsible and for what. E.g. if you put a door of certain size in your wall and the structural engineer would change those dimensions directly in the model who would be liable?, or actually how would you track down the responsibility for this change. The way forward is referenced model approach - that is any external model is used for a reference only and must not be altered. Any change required in that model should be requested from the model author (this is where IFC together with BCF is incredibly powerful), and reloaded again.
In the UK the body that looks after all architects (Royal Institute of British Architects) explicitly says that the workflow should be done by using referenced model approach. This fact is worked in all legal BIM-related addendums to different procurements contracts maintained by RIBA. So even Revit workflow that is reliant on .rvt format would not be able to utilise element sharing between professions according the rules (as everyone must be responsible for their own bit).
One more thing at the end. IFC transfer needs to be set up properly and there is no magic button to set it up correctly outright. I would suggest to create a BIM protocol for your consultants - that is how model information should be correctly structured. I guess if I draw a parallel with 2D CAD it is like agreeing on what kind of line types and layers you will use in your .dwg file or whatever. If you do not do this you will face to a mess.

[Michael]

This is a good thread an appropriate for an internal issue faced in the workplace.

Has any developments in video format been posted for AC18 and Revit 2015 of late?

This whole discussion certainly demonstrates the need for open (BIM) standards and interoperability of chosen software platforms, yes ?!

[DGSketcher]

An interesting thread. I appreciate the use of IFC to cross reference between different consultants, but it is hugely disappointing for architectural collaboration. It makes the problems of 2D exchange look pretty simple in comparison. Guess you pick your horse and run with it...

[Anonymous]

Ransom, Do you know how to get Revit MEP objects to come into ArchiCAD MEP on individual layers? In the IFC Translation setup, we selected "Place Imported Elements on Imported layers", but they all come in on the same layer. I understand Revit doesn't use layers, but is there a way to translate Revit Systems to specific layers?