Revit-ArchiCAD Interoperability

[Anonymous]

Just wondering if people can share their experiences with the IFC translators in v14 between Revit and ArchiCAD.

We have had limited success with this. In doing a test we have found we can correctly export a IFC file that can then be read in Revit Structure via the Graphisoft IFC add-on for Revit. And can do the same in the other direction.

The 'detect changes' function works very well, highlight what has changed, what is new, what has been deleted etc. This seemed very stable. Merge and others are also good.

The big failing however is that it is essentially a one-way communication. I don’t consider this interoperability as Graphisoft advertises. It is a small step maybe but it misses the big issue. As an example if..

1. I draw a column and export to IFC in ArchiCAD
2. Revit structure imports the column via IFC
3. they change the column size and then re-export
4. ArchiCAD imports the drawing again.

In this process I now have 2 columns, one I originally drew and one by the structural engineer. I can then either

1. accept the structural engineers column in which I delete mine and therefore lose all documentation attached such as dimensions and labels OR
2. delete the structural engineers column and change the size of mine. This option seems like a variation on what we currently do rather than any advance in interoperability.

There are many meanings to what interoperability is but I think the main issue is that we don’t need to keep 2 versions of the same model, in this case the structure engineer draws the structure, the architects draws the architecture.

I think it is easy to blame Revit for these issues as I know Graphisoft are trying to get this working, even by making their own add-ons for Revit but in reality, as an architectural practice, we need to compete with Revit Architecture users who link seamlessly with Revit Structure.

[owen]

Mark,

Good points and all problems we are facing today

It is possible to run with Option 1 (dimension to the Structural engineers column) but inevitably the problem of missing dimensions will arise - probably right before a deadline. The issue is where the structural engineer deletes and replaces the column in their software rather than just modifying the existing - AFAIK this gives the column a new GUID when exported to IFC and so ArchiCAD cannot find the previous column the dimensions are associated to. Its the same issue we face in ArchiCAD, just further complicated by the modelling being done in another office and not by the guy at the next desk.

Therefore a variant of Option 2 is unfortunately the best way to go in my experience. Hotlink the Structural IFC file in for reference (run 'Detect Changes' against, etc) but dimension to your own architectural structure model which is coordinated (manually) with the IFC file.

I think this simple yet fundamental problem with IFC exchange and how elements are identified - can't really think of a solution ... other than waiting for the day we no longer produce dimensioned drawings but hand over an accurate 3D model which construction setouts are extracted from on site.

I imagine they would face similar problems in Revit Arch <> Structure exchange though .. a new column replacing a superseded one is a still new column in the database, so how does the dimension know whats what?

cheers,

owen

[Link]

Valid points and probably the best solutions so far. Interoperability and indeed BIM can mean many things to many people!

AFAIK this is the first decent iteration of IFC exchange from Graphisoft, where the IFC is only really going to be useful as a 'reference'.

The next iteration I believe (and hope) is going to head towards full round-trip exchange where, in this case, the structural model will come back into our architectural model and be used for documentation. For that to happen, we'll need DWG translator-like setting (eg.pen mapping), 'finishes only' PSD options, etc, etc, just to get started.

So, as IFC matures, I think we'll see ArchiCAD's 'interoperability' mature also. Until then I guess we'll have to get by somewhat manually.

Cheers,
Link.

[Anonymous]

I was hoping someone might point out i am missing something in how it was translated oh well...

Owen: You are correct. When the structural engineer imported our ifc file some of the columns needed to be changed to the correct revit family so straight away it loses its associativity when it comes back to us.

Link: Agree. However while i agree IFC needs to mature and will keep maturing for its life it is still a very good standard as it stands. I think it is now up to the product providers like Graphisoft and Autodesk to catch up to the what is already being provided through a efficient translator to IFC. For instance the GUID should not have to change when it moves between programs. Full marks to Graphisoft for doing what they done so far but we need it to get much better quickly or we will miss a large part of the BIM wagon in working with other consultants on the same job.

Unfortuately as always with this type of discussion it comes down to how much the suppliers what to play with other software. In Autodesks case they dont have much reason too since they offer nearly a full array of products.

This could all be potentially solved if IFC became the base of programs and their method of file storage. I think Solibri do this now??? In my opinion ArchiCADs BIM server should be based on IFC.

[Link]

Mark wrote:
Link: Agree. However while i agree IFC needs to mature and will keep maturing for its life it is still a very good standard as it stands. I think it is now up to the product providers like Graphisoft and Autodesk to catch up to the what is already being provided through a efficient translator to IFC. For instance the GUID should not have to change when it moves between programs. Full marks to Graphisoft for doing what they done so far but we need it to get much better quickly or we will miss a large part of the BIM wagon in working with other consultants on the same job.

So you're suggesting that GS needs to catch to IFC? I don't know the situation intimately enough to judge, but during AC14 beta GS seemed to have a justifiable reason for everything they had created so far. It gave me the impression that any shortcoming was out of their control, either because IFC was not mature enough, or that the other softwares were not capable of interpreting the elements. If GS had to make Revit add-ins for Autodesk, it doesn't surprise me that their software falls short with interoperability. And as you say, why would they want to play well with others, when all they've ever really been interested in is cornering the market and making bank.

In any case, I think we just have to wait...

Cheers,
Link.

[owen]

guys,

I've made a post regarding IFC Save times ... in hind sight perhaps could have been added here but didn't as it is not specific to Revit-AC Interoperability (although exactly why i need to do it in this instance)

IFC 'Save As' times

cheers,

os

[Anonymous]

Bump,

To shed a little light on IFC into Revit that may explain some of this behaviour. Revit is built on families and types. When IFC is opened (read imported) all non-system family objects (everything except walls, floors, ceilings, roofs, slabs, pads) are generated as "in place families". These cannot be modified in the revit project interface (they can me modified thru the in place editor), and will not work with any of the 'normal' revit workflow or allow scheduling, etc. (so not at all useful to the structural guys and why they appear to throw away your columns/beams). Unfortunately there is no way of turning an in place family into a normal revit family, so the GUID will change, making it a different object as far as each package is concerned. Ask your structural engineer to look into nesting a shared revit column/beam inside the in place family as this would retain the GUID. I can see a whole pile of time/coordination issues if this workaround was to work though it may be a temporary fix on smaller jobs...

[Anonymous]

The columns and beams should not (typically) be importing as in place families but as fully functional columns and beams (though there are exceptions for unusual geometry). This works both ways in my experience with GS' Revit add-in improving the process significantly.

Mark's original post has to do with the workflow issue of whose structural model to use. To modify the original architect's model or to replace it with the revised engineer's model. I think this is more of a practice and standards issue to be solved at the operational level than one to be automated.

Perhaps I'm missing something but it seems to me that once the engineer has taken over the structural modeling theirs should supersede the architect's version. Just as the detailer's model will replace the engineer's in the construction coordination model.

[Anonymous]

Matthew wrote:
The columns and beams should not (typically) be importing as in place families but as fully functional columns and beams (though there are exceptions for unusual geometry). This works both ways in my experience with GS' Revit add-in improving the process significantly.

This is good to hear. I have only played with MEP interoperability, which sucks as suggested above.

[Karl Ottenstein]

Appreciate all of this new-to-me info, as I have not had any IFC-to-Revit experience other than hearing of some issues in one colleague's export.

So, are you saying that even if a beam is modeled in ArchiCAD as an object (one of the steel beam objects) and tagged as a IFC beam class, that Revit will see it as a beam Matthew? Or, BIMTIM, will Revit see the object-as-beam as an "in place family"?

Similarly, my friend had a floor slab that had edges trimmed by Solid Element subtraction. This exported to IFC as an object, rather than a slab - although still tagged as IFC slab category in the IFC viewers that we used to look at it.

Would such as slab (or other SEOp-trimmed building element) be seen by Revit as an actual floor slab, or will it be an "in place family"?

Thanks,
Karl