Incorrect "Join" for Steel Beams causing error in analysis model

[Anonymous]

I had a problem when importing a model from our Analysis/Design Product using our own Import command and managed to reproduce the issue in the attached Solution.

Basically, in one part of a particular user's model, we have two steel beams joined end-to-end and a third beam attached a small distance away - see Required Model.png.

But because of the order in which the beams are created, Revit decides to join the wrong pair of beams end-to-end and the other beam is not connected - see Wrong Model.png.

Putting aside for a moment the problem of detecting this situation in the middle of the import, I cannot do the obvious and unjoin the wrong beams because they are steel beams, not concrete! 

The solution includes some debugging code to detect what elements are at the ends of each beam etc and two experiments to correct the problem. 

Experiment 1 - swap the order of elements at the wrong join - did not seem to make any difference.

Experiment 2 - delete one of the beams (order is vital); do a regen; re-create; do another re-gen seemed to work. Just uncomment the code to see.

Obviously, the size of beams affects the joins - so run the command in the attached .rvt file

Anyone got any comments or suggestions?

[Anonymous]

As an alternative approach, instead of detecting when this happens and then attempting to repair it after the fact, it might be possible to avoid it all together.

Try doing a first pass on the imported data to grab a list of beams that are joined at common end points. Add these to the model first and set up joins. Commit the transaction then do a second pass to add in the intermediate beams. Revit should then leave the existing joins intact.

I haven't tried this or anything similar, so it's just an idea. Hopefully I've been of some help.

[Anonymous]

Thanks for the suggestion - I was already thinking along those lines as a work-around. It isn't quite as simple as it sounds, e.g. I would need to ignore beams joined to columns as well as beams in that pass. 

The problem is that we already have to do a few manual regens and add in the ones that Revit does internally (despite being in manual mode), and larger models take ages to import. So I was hoping to avoid another pass and regen - committing the transaction will always do that.

Do you agree with the principle of Revit changing the start and end positions of the beam? I can't understand why it has to do that. It should leave the Location Line as defined and just adjust the graphical view if necessary. We set the analysis model of imported members to Location Line because the Auto Detect is wrong in so many situations and this is another example where the automatic behaviour is wrong and there seems to no way of overriding it except something like you suggested.

[Anonymous]

Yeah it's quite annoying, I do come across the problem in one of my addons. Fortunately the beams are created during an interactive process and the user is able to undo and adjust as required.

It would be nice if Revit's automatic join / constraint generation was not applied to API created elements unless specificly instructed to do so, I'd even settle for a "Do not mess with my geometry please" optional parameter tagged onto the family creation methods. I guess the problem then is how to define / control the interaction of user-created and API elements, so it's probably a can of worms that is best left closed for now.