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

Sound_Spinning

jacob
Thanks, I'll get back after running your model.

That is exactly what I am after, replace parts in assys --> re-run.
But, you imply that constraining all slaves (defaults w/out the max_dist entry) is fine. For that to be true in real life assys then always, all slave surfs must lay inside the master surf boundary. That is not what tends to happen in production with many parts. Then you'd have, each time, to partition, plan your new slave surfaces for the defaults to work; and that takes time each time. That is my main point from what I've seen so far in code_aster with tied contacts.
Your test model is an idealisation of the above, same size surfs on flat surfs, alligned perfectly in front of each other, not often the case in design.

jacob

Can you give some specific "complicated" example and how you would treat it in some commercial tool, if the two cubes are for you "too ideal"?
I have worked with patran, ansys, solidworks and I don't see much different behavior in CA. Or you imply some "automatic selection for bonding"?

What do you mean by "all slave surfs must lay inside the master surf boundary" ? LIAISON_MAIL works like this:
slave - group of face elements
master - group of volume elements

If there is some gap between them, slave surf will be projected to surface of master volume and bonded, regardless the gap value so there may be "some imperfections".
If you don't want to connect all slave then you can specify DIST_MAX. For example if blue surface is your slave then without specifying DIST_MAX, it will all connect to master, if you specify DIST_MAX = 2, and there will be gap =1, only part of the surface will be connected.

jeanpierreaubry

jacob
hello

do not you think DISTANCE_MAX is not a vertical distance but a true space distance?
radius of a sphere from the SLAVE node
which i some case may make the influenced area on MASTER quite large

jean pierre aubry

Sound_Spinning

jacob
On your query abt other codes, where is all pretty much automated, except edge cases with bad CAD; see this entry here in this thread.

Also see my 1st post in this thread, to (maybe) understand better where I'm coming from with this. It is not as trivial as some of you put it. There are several ways to deal with search algos in contacts, and code_aster does not use a clever one on tied contacts.

jacob

yeah, the picture would be correct if I switched the slave and master, then the normal would be vertical. So in the picture the DIST_MAX > 2

jeanpierreaubry

jacob
in your sketch if you specify DIST_MAX =4 all the element in Master will be taken into account
DIST_MAX may be horizontal at most
right ?

jacob

it will be bonded where the circles penetrate, in this case DIST_MAX = 10

regarding no DIST_MAX, it will probably be max distance from nodal normals, but I don't have a proof
(I draw only border nodes, for visualization)

Sound_Spinning

[ SOLVED ] at least for most general cases I found...

OK, (I think) I now have an automated way to deal with code_aster defaults in tied contacts (LIAISON_MAIL).
This now doesn't need manual tweaks in UIs of slave CAD or node sets; and no use of DISTANCE_MAX in tied contact definition.
If we create the slave node set with this syntax 1st (see below); it turns out that the default search distance does use a relative value with respect to the mesh size, which is one of the things we are missing in LIAISON_MAIL defaults.
Then, it doesn't matter by how much the original slave side 'misses' the master side.

# auto-trim slave node sets for tied contacts
DEFI_GROUP(reuse = mesh, MAILLAGE = mesh,
           CREA_GROUP_NO = (
                            _F(
                               OPTION = "INCLUSION" ,
                               CAS_FIGURE = "3D",
                               NOM = 'trim_slv_1_srf',
                               GROUP_MA = 'slv_1_srf_els',
                               GROUP_MA_INCL = 'mst_1_srf_els', 
                               ## DISTANCE_MAX = 1.1,  ## gap + 0.1mm between cubes, IF required.
                              ),
                           ),
          );

All tests so far work now, and I don't see the invisible over-constrain on rots DoF, both static moment loads & modal without constraints now nicely give 6 0Hz rigid body modes.

SUMMARY of test models (2 cubes) showing all:
1.- bad_tied_coups_2_cubes.zip
If you open the .dat file, you'll see the reaction moments for LCs 4, 5, 6 totally out. Then modes 4 --> 6 in modal w/out constraints all wrong (over-constrained), as they are not near 0Hz.

2.- auto_tied_coups_2_cubes.zip
Here in .dat file, we see all working perfectly & 6 0Hz modes in modal, without changing anything in the model. Sweet!

3.- auto_gap_tied_coups_2_cubes.zip
Here we have a gap = 1mm between the cubes, it still works, see dist_max in node set creation.

If developers read this, it'd be helpful please, to carry over the logic on defaults you have in command above to the LIAISON_MAIL defaults, or else one can easily get the results wrong in assemblies, and it is not an easy one to spot from 3D contours (or impossible even).

Thanks.

jacob

EDIT: no, in case of no DIST_MAX the normals will be taken from a master, so in this case it will be max vertical distance.

jacob

I looked at you files, so i think the issue you are talking about is that all slave surface is connected to master and not only projected area? But this can be solved by using appropriate DIST_MAX value, so why creating some group intersection?

jeanpierreaubry

jacob

I looked at you files, so i think the issue you are talking about is that all slave surface is connected to master and not only projected area? But this can be solved by using appropriate DIST_MAX value, so why creating some group intersection?

that is it
no needs of fool's errand

Sound_Spinning

jacob
Because LIAISON_MAIL does NOT have a default relative search distance wrt the mesh size.
That is a killer when you have say 20 tied pairs in an assembly; otherwise you're right, dist_max in tied definition should have worked, but it doesn't do the same job.
I've tried to describe that issue for a long time, but I get it forums need time to digest, and s'times we do not have the time.
1st thread on the issue with a radar assy

So, it is not the same via set creation vs tied definition, in code_aster that is.

jacob

but it true that if you create your slave using CREA_GROUP_NO = (
_F(
OPTION = "INCLUSION" ,
you don't have to specify DIST_MAX if the surfaces are aligned, if they are not you have to specify it anyway..
Also, this will give different result because you treat group_no and not ma.

jacob

Alright, I now find out that for large distance the moment reactions are wrong, It should be 45e3 but it is 40e3

for this configuration it is completely wrong without DIST_MAX (26000)

however for DIST_MAX = 0.01 it is correct 45000.
thanks for learning that, but I still don't understand why this is happening.
So I guess you really have to have nice mesh without large gaps and use DIST_MAX, however so far I always have done this when I use mesh connections.

Note: Commercial software usually have also bonded "contact", which uses contact algorithm but additionally constraining tension and tangential direction. In CA using GLISSARE="OUI" user can constrain tension. However there is not possible to constrain tangential direction.

Sound_Spinning

jacob
I think you're getting there now understanding, and how dangerous it can be. It's an 'invisible' rotational constraint (ala rigid body way). It was well know in the 90s when Abaqus et al 1st implemented tied contacts, but they fixed that later.

This is the sketch I used in another post to try to explain the 'why'.
In other codes, slave nodes can be adjusted on top of masters, before the constraint comes into place, so that the rots over-constraint doesn't happen. But you need also a proper contact look up on what intersects the master 1st.

jacob

Alright, but I still don't understand what it the difference between using dist_max and creating your projected node group.

Sound_Spinning

jacob

Node set projected method uses a relative search tolerance wrt mesh size. It understands the topology of the master side (roughly). So, I do not have to use dist_max on this one. Except the one with gaps, coz code_aster doesn't have an adjust option to move the slave nodes, then we are down to luck if it gives the correct moments.
This saves a lot of time in pre-FEA / debugging as it tends to do a very decent job on a 1st shot on tied pairs w/out guessing, then you only tweak manually the difficult CAD ones, where designers rushed thru design changes, and quite commonly, things don't line up mating nicely, not only on outer boundary, but drills, etc.
LIAISON_MAIL --> dist_max option requires a guess 1st as it doesn't understand the master topology, unless you inspect all tied pairs painstakingly in the UI, and it is close to impossible to check all manually on real complex assemblies.
Then in code_aster, you'll need to keep re-running guesses, but without over-constraining the model up (when too large a guess distance), since, sadly by default, code_aster just pulls ALL slave nodes onto whatever is the closest to the master side, w/out checking if there should be a real intersection.

See my very 1st post, the graphs. For dist_max=1mm the results are already wrong, but I have a tet size=17mm. How would you know that a distance < 10% elem_size gets it wrong?
See zooming in on the 1st 6 modes. Note s'thing else: why for dist > 2mm it keeps getting it even worse, when it should have already found the nodes meeting the master? The node set method bypasses that, if no significant gaps.

Makes sense? Happy to try again.

I think you guys should forget abt my silly, tiny assy models as the real case; they are just for method development. Then imagine a large assy with many parts, and many tied contacts. In that case, the node set 1st filtering method wins big time to get to a good start fast, as it is based on the topology of the master side geometry (mesh).
And you still should check all your reactions sums and total force/moment vectors thru each tied pair, or else, it may be all wrong. Same with the check on a quick modal w/out constraints till you get 1st 6 modes near 0Hz.
There is a 2nd benefit of the node set pass 1st: when you request the force/moment sums at each tied pair, you know exactly what nodes are constrained. If you use the tied dist_max option, you don't, and the sum is out most of the time, have checked several times; coz it includes nodes that were not constrained and pollutes the sum.

If code_aster did get the dist_max on tied definition the same as with the node set one, we wouldn't even have this thread. See my very 1st post with defaults, all out by default. Forget for a minute this model is an easy one to guess, it is to develop a method to see if we can go large, while getting the rots stiffness / moments correct.

jacob

Well, in 99 % cases when I use it, for example:

I don't have an exceeding slave surface, thus I am connecting whole slave anyway.
Maybe that's probably why I never encounter any problems, and that is the reason why they didn't spend any time to solve this problem.

"dist_max option requires a guess 1st as it doesn't understand the master topology, unless you inspect all tied pairs painstakingly in the UI, and it is close to impossible to check all manually on real complex assemblies."
Well, you have to repair a geometry, create mesh and select all slave surfaces manually so I don't know how you would avoid it anyway.

But I still don't get it, using very small DIST_MAX (0.01 - 0.001) behaves the same as creating the group. And if I use the same DIST_MAX in LIASION_MAIL or in CREA_GROUP_NO I get the same results.

Sound_Spinning

jacob
In your examples yes, in my experience things are not as neat as you put it, I hardly ever had to prepare much on tied contacts with other codes, it is very fast to make them work even with gaps / overlaps.
I think it is all good if it works for you. It doesn't for me in production on large assemblies, we don't spend time making things nice & tidy for FEA till validation stage on final approved design before prototyping.

Different needs.
Do make sure tho your reactions in statics and modal analysis, rotational/nodding modes, are correct, as you've seen, they can go wrong quickly even on a very simple model.

By the way, contact pairs are not prepared manually in decent UIs (check e.g. PrePoMax as open source). It is an automated process in all commercial UIs I've seen too, and you just visually check they make sense, and do very minnor manual edits.

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

jacob

what about this ?
"But I still don't get it, using very small DIST_MAX (0.01 - 0.001) behaves the same as creating the group. And if I use the same DIST_MAX in LIASION_MAIL or in CREA_GROUP_NO I get the same results."

"I think it is all good if it works for you. It doesn't for me in production on large assemblies, we don't spend time making things nice & tidy for FEA till validation stage on final approved design before prototyping."
Usually, it is better to use continuous mesh anyway.

"Do make sure tho your reactions in statics and modal analysis, rotational/nodding modes, are correct, as you've seen, they can go wrong quickly even on a very simple model."
Yes, but if your gap between parts is not visually large and you connect all slave nodes, it is ok.
I must also point out that LIAISON_MAIL is not equivalent to bonded contact in other software, because it is command for coupling between slave group and projected master group and you can use it for cyclic boundary condition too, for example.

"By the way, contact pairs are not prepared manually in decent UIs (check e.g. PrePoMax as open source). It is an automated process in all commercial UIs I've seen too, and you just visually check they make sense, and do very minnor manual edits."
Well, code_aster is just a solver and this is related to preprocessor.

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.

« Previous Page Next Page »