TIED Contact Constraint [ LIAISON_MAIL/TYPE_RACCORD = "MASSIF" ] not working (?)

Sound_Spinning

jacob
As I said, if it works for you, good stuff; there are many ways to FEA anything, as long as it supplies the required and useful answers, it's all good and valid.

jeanpierreaubry

Sound_Spinning
i have put this subject on my bench again
building a mesh with the two cubes making one solid block of the same shape
thus discarding the LIAISON_MAIL

the first six 6 modes range from 0.28 to 22.9 Hz, the first elastic one is 6762 Hz

while with the LIAISON_MAIL and DISTANCE_MAX=0.05 the values are:
first six 6 modes range from 0.23 to 14.1 Hz, the first elastic one is 6130 Hz

we can see that the numerical values of the rigid body mode are not null although very small compared to the first elastic one
this is most probably due to the "silly" (as you said yourself) geometry and mesh of this example
which produces numerical approximation?

second point
replacing LIAISON_RBE3 by LIAISON_SOLIDE does not change anything
again this is most probably due to the "silly" geometry
the MAIT of the RBE3 is so far away from the ESCL that the distance is almost the same
obviating the "advantages" of LIAISON_RBE3 over LIAISON_SOLIDE in this very example

third point
removing altogether the end coupling brings the rigid body mode to an epsilon value

Sound_Spinning

jeanpierreaubry
Hi again, thanks for 2 x checking the models up.

The modal with no constraints should give 6 rigid body modes at (near) 0Hz no matter what. This is a very simple model, a linear system and it is a pure hand calc from geometry and simple physics. Not buying the "numerical approx." argument, sorry.

The cubes are 50mm side; i.e. intentionally very stiff, so we don't care about the freq values from Mode#7 onwards, we just need to see zero or high. Not looking at absolute results on these models.

The cubes with tied contact and the auto node set creation with no use of dist_max method reported in the past, works straight out of the pot, 6 0Hz modes & reactions and tied pair sum of moments correct.
See files here: chk_auto_coups_2_cubes.zip
Same as with the 'welded' version of the cubes: 1part_cubes.zip.

The shells thread also show similar issues, different models. Even the NAFEMS benchmark for the modal shows the issue on modes 4,5,6 for "DKT" elems, while "coque_3D" and "tet10" are fine, so no model side issues, must be the code.
In that thread, my very 1st post was actually abt a (potential) bug with tied contacts + coque_3D elems, but nobody has even mentioned that.

You are correct about soft (RBE3) vs rigid (SOLIDE) couplings, but the cubes are very stiff intentionally.
I avoid the use of any rigid couplings/connections as they get things wrong as a general method. Here is what I posted in another thread on the matter:

Let me know your thoughts, but something is up with rotational DoF ala rigid body, on sum of reactions with tied contacts, sum of moments through tied pairs & modal with no constraints, on many models now, including some 'real' assemblies I translated into code_aster; hence later posting these silly models, which illustrate the issues enough.

Cheers,
Jesus

jacob

Using LIAISON_MAIL when there is a gap between bonded parts, gives a wrong moment, because the rotation is not transferred.

Using MASSIF_COQUE solves the problem.

Sound_Spinning

jacob
Tied contacts in code_aster between solids can be very iffy, as I tried to illustrate in the past in these threads.
Have you tried outputting a table of the sum of forces & moments going thru the tied pair? That may give you a clue. Often the sum of moments is out, by a lot in some cases.

When you add shells, then you have rots DoF on the tie, which is a different case. With solids and a gap I think code_aster over-constraints the rots DoF, and 'eats' away the moments, so don't make it to the restrained areas. It's like an invisible constraint. It's worth having these tied pair tables for force/moments, you may be surprised on assemblies, stuff disappears....

jacob

For DKT there si no problem even with a gap.

jacob

But you pointed it out only when there are more constrained slave nodes than should be. Using distance max etc. leads to correct results.

How can you calculate sum of moments in some pair, since moment is calculated always with respect to some point.

No, with gap it doesn't do anything with moment because solids don't have rotational dof, as I showed above, and that leads to that some moment "disappears".

Sound_Spinning

jacob
The type of loads thru a tied contact pair are not related to the DoF of each node, but a 'net' sum of all forces/moments per DoF on a surface like. In the same way that an object meshed with tets (only disps on nodes) still has 6 rigid body DoF, inc. rotations.

In statics, if the complete model is constrained properly, the net sum of moments wrt any point should be zero; or else it is dynamics. That means rigid body like sums using both all input loads and reactions.

The cases I found with issues on tied contacts are:

with gaps - case dependant.
with a large dist_max value, maybe when applied by mistake.
with curved surf pairs, complex mesh in assemblies with many pairs.
with cylindrical surfs pair - sometimes, depends on faceting.

An old trick to check that tied contacts are not eating away moment forces is to solve a free-free modal. It should give you always 6 RBModes at near 0Hz. With some assys I tried, modes 4,5,6 (rot ones) were never near 0Hz.
In some cases I even had to turn off a specific tied pair constraint for the model to even solve; and so it goes on.

jacob

Well, but still it is possible to have a complex correct model.

All welds are bonded.

Sound_Spinning

jacob
Indeed, FEA is very application dependant, and it'll always be. Golden rules rarely apply to all.
All I'm saying is that, specifically with tied contacts in code_aster, one should always output the tables for sum of forces/moments thru each pair, and really check on moments sum & free-free modal; i.e. 6 0Hz modes.
Then call it with engineering judgement based on results and objectives required.

Let's not forget: "all models are wrong, but some are useful".

As for cases with bad tied moments/rots I also reported a few in this tied shells thread; see the fig in that post for DKT elems.

jacob

I tried to do a modal also with 3D+DKT

the frequencies are about 0, but aster complains that the norm error is too huge. Do you know what it means?

If i understand it correctly you have found some issue when connecting two DKT parts?

Sound_Spinning

jacob
Yes, that's correct, see my small models in the shells thread I linked above.

Also, do the check on statics with 6 unit loads, 6 loadcases: 3 Forces & 3 moments, one load per DoF.
By isolating the inputs per DoF you know what you should get on the 3 moments LCs in the tied pairs table sum and all reactions sum. It's a quick check I do in all assys. I've seen free-free modals to work, and then the moments sum reactions to be out in statics; different solvers.

Code_aster seems to have theoretical checks on both statics and modal; I ignore them all and turn defaults off so the job doesn't stop. If it is a wrong setup, I want to 'see' it on the actual results, and not a theory algo to tell me it is wrong.

Just seen in your table that mode#6 (labeled 7) is at 43Hz, not good if it was a free-free modal.

jacob

MODAL = CALC_MODES(CALC_FREQ=F(FREQ=(-1.0, 50.0)),
MATR_MASS=MATRIX_M,
MATR_RIGI=MATRIX_K,
OPTION='BANDE',
SOLVEUR=F(NPREC=12),
VERI_MODE=_F(STOP_ERREUR='NON'))

I have changed the range to 50 (I don't know why it does not give number 1 with range 0-100).

I will try to connect two DKT. I always have continuous mesh when I use shell (it's easy to create, so I don't know why use bonded connections).

Sound_Spinning

jacob
It's common with modal solvers to get slightly negative near zero Hz RBModes, so min=0 won't catch them all.
We normally use a "shift value", all modal solvers have it, and set it below 0. E.g. in code_aster it seems to work like this with n_modes request.

See SEUIL_FREQ = 10, dunno why it is not a negative value in CA, but there you go, it works, and flashes correctly in message file.

Welded meshes across parts with different materials get the stresses wrong, and takes longer to weld parts for complex assys vs tied contacts, which get the stresses right across diff mats.

jacob

I have MODAL = CALC_MODES(CALC_FREQ=F(FREQ=(-1.0, 50.0)),
Solver message says: use BANDE with slightly negative value.

CALC_FREQ=_F(FREQ=(-5.0, 50.0)),

Why for continuous mesh it would be wrong and for bonded mesh not?

Sound_Spinning

jacob
"Why for continuous mesh it would be wrong and for bonded mesh not?"
At the shared (welded) nodes, stress averaging will be mixing things up.
On a contact pair you get both sides separately, if coded properly in solver to get the right net force/moment vectors thru.

jacob

I didn't encounter any problem.

3d
whole / split

DKT whole / split

jacob

https://forum.code-aster.org/public/assets/files/2025-06-12/1749714864-276056-beam-modal.7z

jacob

Well, if the parts are connected by a weld, then the weld alone will have different material properties, or the steel is mixed by some melting process, so there will be residual stresses etc.. Thus, the stress will be "wrong" anyway. You could just read the stress values from the next adjanced element.

mf

jacob
Hello Jacob,

which mesher have you used for the above model?

Thanks, Mario.

Sound_Spinning

jacob
As we said in the past, if it works for you, good stuff.
You are diverting tho.... it's enough linear mats with diff E values, e.g. steel :: aluminium. And I'm never implying that you are doing anything wrong, just giving pointers as to why I need what I do when I post stuff.
It's all application dependant, and good eng. judgement.

« Previous Page Next Page »