Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban

You are not logged in.

- Topics: Active | Unanswered

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

Hi,

Yes, I know I should use HEXA27 for contact with friction and that works well. But I wanted to see if it was possible to solve a small test case with tetra elements in contact with friction.

The problem is a fork-pin connection. The fork is constrained in all dofs. The pin is constrained not to translate along its axis DZ=0 and with discrete spring stiffness not to rotate unlimited about its axis DRZ. The idea is to transfer a force FY and a torque MZ through the connection.

Step 1.0 – Apply F and establish contact with low friction my1. E.g.my1=0.000001.

Step 2.0 – Maintain F and increase friction to my2. E.g.my2=0.15

Step 3.0 – Apply torque M to be transferred (mostly as friction but partly also to the discrete spring)

The friction capacity in the contact is higher than M. Therefore there should not be any large rotation/displacement. Also as a safety measure the spring stiffness is adjusted so that without friction the rotation due to M is only 0.1degrees.

The number of degrees of freedom is small (~11000nodes). Without friction the problem solves in about one minute. With friction I have only had the patience to solve up to step 2.3. I use the contact algorithm: FORMULATION='CONTINUE'.

Some observations:

-Using my1=0.0 and my2>0.0 fail when the results are written to the med file due to the number of DEPL results between the two cases do not match.

-Using my1=0.000001 fail due to that the system is singular in step 1. With NPREC=-1 it solves ok.

-The test case runs well without friction(my1=my2=0.0). With friction (my1=1e-6 and my2=0.15 a lot of iterations are needed in step 2 and 3. The results seem ok. The convergence takes time and it does not seem robust (see for example the jumps in CRIT. FROT. from e-2 to e-4 below):

| 1 X | 30 X | 1.60615E-04 X | 1.63378E+01 |ELASTIQUE | 0 | 2.10226E-03 X | 3.73929E-04 | |

| 1 X | 31 X | 3.69833E-05 X | 3.76195E+00 |ELASTIQUE | 0 | 4.79464E-04 | 9.30105E-05 | |

| 1 X | 32 X | 2.28829E-04 X | 2.32766E+01 |ELASTIQUE | 0 | 2.03460E-03 X | 3.17150E-04 | |

| 1 X | 33 X | 1.99759E-05 X | 2.03196E+00 |ELASTIQUE | 0 | 4.29132E-04 | 1.18751E-05 | |

| 1 X | 34 X | 1.58256E-04 X | 1.60979E+01 |ELASTIQUE | 0 | 2.76198E-03 X | 2.02311E-04 | |

| 1 X | 35 X | 6.86972E-05 X | 6.98790E+00 |ELASTIQUE | 0 | 2.11328E-03 X | 2.95893E-04 | |

| 1 X | 36 X | 9.30608E-05 X | 9.46617E+00 |ELASTIQUE | 0 | 2.91368E-02 X | 1.87510E-03 | |

| 1 X | 37 X | 2.06230E-03 X | 2.09778E+02 |ELASTIQUE | 0 | 2.68789E-02 X | 3.87455E-04 | |

| 1 X | 38 X | 2.65462E-03 X | 2.70028E+02 |ELASTIQUE | 0 | 2.33420E-02 X | 1.03028E-03 | |

| 1 X | 39 X | 1.86825E-03 X | 1.90039E+02 |ELASTIQUE | 0 | 4.36564E-02 X | 1.63178E-03 | |

| 1 X | 40 X | 1.89379E-03 X | 1.92637E+02 |ELASTIQUE | 0 | 1.97004E-02 X | 4.11560E-04 | |

| 1 X | 41 X | 1.97572E-04 X | 2.00971E+01 |ELASTIQUE | 0 | 9.00320E-04 | 1.56131E-04 | |

| 1 X | 42 X | 1.48757E-04 X | 1.51316E+01 |ELASTIQUE | 0 | 2.79090E-02 X | 1.21201E-03 | |

| 1 X | 43 X | 1.30304E-03 X | 1.32545E+02 |ELASTIQUE | 0 | 1.50305E-02 X | 4.05568E-04 | |

-Between step 1.0 and 2.0 there is very lite change in load. I have also tried with no load change at all from 1.0 to 2.0. The problem then seem more complicated with even more iterations. -With a converge solution for step 1 and only increasing the coefficient of friction, should not the solution for step 2 be trivial (equal to step 1)? – if so why is this step so difficult for the solver?

Suggestions how to improve the performance are welcome? Can the convergence be made faster or more robust? -Or is this the expected performance of tetras in contact with friction? Please post your best trick how to make this solve better .

BR/Micke

*Last edited by mihe (2021-11-10 10:39:38)*

Salome Meca 2019 on Ubuntu 18

Offline

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

The mesh.

Salome Meca 2019 on Ubuntu 18

Offline

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

Any inputs for faster and/or more robust convergence are welcome! Also if someone can explain why the load step from 1.0 to 2.0 is so difficult for the solver (same load, only changing the coefficient of friction).

BR/Micke

Salome Meca 2019 on Ubuntu 18

Offline

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

After more testing it seems that Using, ALGO_FROT='PENALISATION', solves this problem good. You just need to verify a reasonable value of COEF_PENA_FROT to use.

Document U2.04.04 says: "For studies where adherence is dominating, one will support values of COEF_FROT lower than the value by default(100) while for cases where the slip is dominating, one will choose higher values." -Does this mean that convergens will be faster by doing this? -Or that the accuracy of the calculated slip will be better? -Both? Is the same valid also for COEF_PENA_FROT?

When testing this out I found a interesting/odd result. Even if I force two surfaces to slide relative to each other CA says that some nodes are sticking. See attached case with a box sliding on a plane from instant t=2.0 to t=3.0.

-CA says some nodes are sticking (RTAX, RTAY, RTAZ)!=(0,0,0). See attached picture -Why?

-The slave nodes are on the box -should not the stick/slip efforts be in the other direction?

BR/Micke

Salome Meca 2019 on Ubuntu 18

Offline

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

The Picture/Micke

Salome Meca 2019 on Ubuntu 18

Offline

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

Hi,

As I mentioned above the ALGO_FROT='PENALISATION’ algorithm seem attractive since it stable and relatively fast converges to a solution.

I did a study of how to adjust the COEF_PENA_FROT parameter so that the friction forces would be accurately transferred. See attached pages. However with the simulations I did I found no way to adjust the parameter that would accurately describe the load path in this case. In this study HEXA27 elements are used.

-Is it due to over estimated slip that ALGO_FROT='PENALISATION’ can not accurately describe the load path?

-Do you have any tip how to improve the contact definition (see last page)?

BR/Micke

Salome Meca 2019 on Ubuntu 18

Offline

**mihe****Member**- From: ENGCALengineeringcalculations
- Registered: 2008-04-08
- Posts: 256

It seem that I get much better results if I use ALGO_CONT='PENALISATION’ combined with ALGO_FROT='PENALISATION’. Maybe one should not mix ALGO_CONT=STANDRARD’ and ALGO_FROT='PENALISATION’?.

So first I then need to set a reasonable COEF_PENA_CONT. For DISCRETE formulation the documentation u2.04.04 says:

“One generally chooses E_N by successive tests: • first of all one will start by taking a value equalizes with 10 times the largest Young modulus of the structure multiplied by a length characteristic of this one; “. For CONTINUE formulation I can not find any guide in the documentation. Is it reasonable to use a value similar to E_N?

So for example would it be reasonable, for a simulation with modulus of elasticity 210e3MPa and with a contact diameter of 100mm, to use:

COEF_PENA_CONT=E_N=10*210e3*100=210e6?

Here: code-aster.org/forum2/viewtopic.php?id=24855 a much lower value is suggested: COEF_PENA_CONT=210e3/100=210e1

Which of these values are reasonable to start with? 10*E*size=210e6 or E/100=210e1???

/Micke

*Last edited by mihe (2021-11-10 13:51:08)*

Salome Meca 2019 on Ubuntu 18

Offline

**VonPire****Member**- Registered: 2021-01-14
- Posts: 22

Hello Micke,

Have you tried does the Mortar algorithm work with friction ? At least In DEFI_CONTACT it is possible to use FORMULATION=CONTINUE, ALGO_CONT=LAC, APPARIEMENT=MORTAR, FROTTEMENT=COULOMB, COULOMB=0.1

At least Mortar should work without friction FROTTEMENT=SANS...

Mortar is SEGMENT-SEGMENT or FACE-FACE type contact and should capture penetration and contact pressures very precisely and there is no need to adjust penalization parameters.

Remember that you have to precondition the slave surface with CREA_MAILLAGE, DECOUPE_LAC when using Mortar algorithm.

For more info refer to U4.44.11 (DEFI_CONTACT), U2.04.04 (General info and tips for contacts), R5.03.52 (Continue method), R5.03.55 (Mortar method) and code-aster.org/V2/UPLOAD/DOC/Formations/13-contact-friction.pdf (Contact and friction presentation)

Best regards,

VonPire

*Last edited by VonPire (2021-11-10 15:03:53)*

Offline