Concrete interface between two models

[jth-wspusa]

Hello,

I am working on a project where there are structural models from different firm which have concrete elements that will be joined together.  Specifically, one model has a concrete wall with a corbel to support a concrete slab and a separate model that has a concrete tie-beam that interfaces with that wall and therefore the corbel.  (See image below)

In my model concrete framing elements recognize similar materials and automatically join together.  Is there a way to get the concrete elements between two models to show a similar interface?

The project is using a Navisworks for clash detection and this interface between the two models is flagged as a clash.  It is possible to resolve these specific clashes in the Navisworks analysis but it would be nice if I could address this with-in my model.

[ToanDN]

One or both of the structural models need to revise their model to resolve the clash.  For example, the tie-beam needs to be chamfered to match the corbel, or the corbel needs to be notched at the beam location.

[RPTHOMAS108]

You can't currently do that but I'm not sure it makes sense to do it anyway for that example. Joining in these situations would just mask the lack of underlying coordination between the two models i.e. there is a real world joint so what should that look like?

Is a contractual issue where agreement needs to be found in terms of what takes precedence: tie beam or corbel. You would not ordinarily interface a tie beam into the sloping edge of a corbel. Instead perhaps you would stop and start the corbel (soft jointing over end of tie beam at lower level). Could also do opposite where you run tie beam into wall at same level of corbel, then notch the top of tie beam away from it's ends to allow a soft joint over. You could also instead use alternate corbel profile at tie beam locality (allowing flat interface). Many choices but a joint decision in all respects.

When you consider the amount of reinforcement that goes into a corbel and the anchorage of the end of a tie beam it only makes sense to me to separate the two details out by stopping and starting the corbel. Don't know if this is precast or not so that would form part of the decision.

You can ignore any clash results by element type names etc. when that issue isn't the main focus but long term it's lack of coordination. 

[jth-wspusa]

Effectively all of this will be poured monolithically.  In the real world it will be up to the contractor whether there is a cold joint but there will not be an expansion joint.  Wall, Tie-beam and corbel will all be one mass.  I did not mention before but this work is all below grade.  Precedence is with the tie-beam to wall joint.  The corbel will support a floating slab.  This connection occurs 62 times in the current design.  The opposite end of this tie-beam is into a grade beam with the same corbel which does not trigger a clash detection. 

The point of my post is about the Revit functionality not the concrete design.  If this were one model it would not be a problem.  Unfortunately the clash detection was ran with minimal controls and I am looking for options outside of navisworks to streamline the process but this may just one of those things that has not yet been solved.  I do see how this may be a challenge programmatically. 

It seems that it should be possible when models are using the same global parameters to identify material interfaces that have a cross-model connection, similar to grid monitoring across models.  This actual connection is detailed separately for LOD management.  I generated the section shown just for this posting as it is not shown in this raw form in the drawing set documentation.