Contact friction convergence!

bosman

Hi!

Using LAGRANGIEN formulation for both contact and friction is causing convergence problems

in 10.3, but the same model runs fine in 10.1. I have a previous report on this here

http://www.code-aster.org/forum2/viewtopic.php?id=13539 for an axisymmetric problem.

Recently I have been testing this for a simple 2D plain strain model and basically getting the

same convergence problems. The model consist of a square block on top of a larger block

and the smaller block is moved a certain distance and then back. In 10.1 I get good convergence

and in 10.3 I get convergence but not as quick. The interesting observation is that

I get severe convergence problems with LISSAGE='OUI' in 10.3 but no real problems in 10.1.

I have gone back and reran the test I supplied in the previous post and get the same convergence problem

in 10.3 but not in 10.1 for the LAGRANGIEN formulation for both contact and friction.

I've attached the new test cases for 10.1 and 10.3.

PS! I must add that I think in general the contact convergence has improved tremendously in the later

releases, but there are still some cases causing problems.

Regards!

B-OS

Attached file:
friction.tar.gz, 5600kb

tcdonley

Hi, Bosman and thank you very much for this post. I will look over your model closely in the next few days and follow this thread. I appreciate the insights you have shared in the forum about convergence issues.

I have been struggling with some convergence issues in a proprietary model which includes plasticity of two different aluminum alloys and 5 contact zones. To start troubleshooting my model, I created a relatively simple contact / plasticity test which includes a few base concepts utilized in the more complex proprietary model. That simple model is attached. It, and my employer's model will both converge easily at low loads, but divergence occurs at high loads. The model is a plane strain model of a round copper tip (assumed linear elastic) contacting a soft aluminum plate. Lagrangien formulation is used for contact and friction. I tried a similar model in axisymmetric form, (to take advantage of symmetry and include hoop stress term) but I had much more trouble with convergence in that model.

With much help from the new U2.04.04 (Merci, M. De Soza!!) I have been able to increase the load much higher in the attached model from when I first created the model. This is what improved convergence in this one case:

- avoided extremely fine mesh

- smoothed the "corner" in the stress-strain curve where the slope changes sharply (not sure if this actually helped much)

- switched from quadratic to linear elements

- reduced number of time steps

- added friction (without friction, the round tip begins to roll a little about the Z axis, and friction stabilized this model and allowed a higher load, and is more realistic)

I would love to have help with how to make this converge at higher loads, but I am posting this model here in hopes it might add another data point to this discussion.

Best regards,

- Tim Donley

PS. This has only been run in STA10.3

Attached file:
Hertz_ctc.tar, 102400kb

ThomasDESOZA

Hi,

bosman wrote:
Using LAGRANGIEN formulation for both contact and friction is causing convergence problems

in 10.3, but the same model runs fine in 10.1. I have a previous report on this here

http://www.code-aster.org/forum2/viewtopic.php?id=13539 for an axisymmetric problem.

Recently I have been testing this for a simple 2D plain strain model and basically getting the

same convergence problems. The model consist of a square block on top of a larger block

and the smaller block is moved a certain distance and then back. In 10.1 I get good convergence

and in 10.3 I get convergence but not as quick.

We indeed did not take the time yet to fix the problems you reported a year ago in the thread mentioned above (the entry is still open in our bugtracker).

Last year effort has been put on the improving of the 'CONTINUE' method of contact particularly regarding :

- ease of use ("smart" default parameters for geometric convergence have been selected, fewer keywords now need to be tweaked)

- studies with friction (convergence was improved and redundancy with boundary conditions can now be taken into account)

- performance (drastic speed up may be observed for linear elastic studies between 10.1 and 10.3)

Regarding discrete methods of contact (FORMULATION='DISCRETE'), performance in big studies for penalized contact ('PENALISATION') was improved between 10.2 and 10.3. Discrete methods have also benefited from the increased ease-of-use.

However nothing was done yet for the LAGRANGIEN method. We plan to fix it this year.

bosman wrote:
The interesting observation is that I get severe convergence problems with LISSAGE='OUI' in 10.3 but no real problems in 10.1.

This is interesting and surprising since bugs were fixed for the LISSAGE (smoothing) feature and we have shown that it can drastically improve geometric convergence for coarse meshes.

I did not have a look at your files yet but can we observe that with them ?

TdS

bosman

Hi!

Tim:

I had a quick look at your model and I got a question. What kind of load do you want to apply

to the model? Initial response is that there is lots of plasticity and if one increase the load

it gets close ideal plasticity as the stress/strain curve becomes more or less flat. There are a couple

of things that could be done to the model to maybe get a better response, but I have to get back to

you later on this.

Thomas:

Yes! The LISSAGE issue can be seen in the model. In this test case it's a flat surface so it should

not really need smoothing of the master surface, but I thought it was an interesting observation

that it created such a problem for the friction formulation.

And I agree that there have been some really good developments that has helped in making it easier

to use contact in Aster.

Regards!

B-O

Claws

I thought I'd tune in with a test/benchmark I did recently. It involves a lead bullet, that with high velocity hits a thick but deformable plate.

The lead bullet is allowed plastic deformation while the plate remains (unrealistically) elastic.

I ran the simulation with with the different contact formulations to see which, if any, would come out on top of the list.

The lead bullet uses deformation=GDEF_LOG whereas the plate uses PETIT (should have been SIMO/MIEHE but I forgot to change it) - there is however, no friction used this time around.

Time [s]:

Constraine: 2337.87

Continue: 989.09

GCP: 2114.19

Lagrangien: 2318.58

Penalisation: 1080.75

Deformation can be seen the following two pics (order is the same as above) - notably the penalisation and continue deformation is 'weird' for a lack of a better word, probably a mistake on my part? Those two also completes in half the time of the other formulations.

Make of it what you will :)

Attached file:
Deformation.zip, 63559kb

Claws

...forgot the initial condition.

Attached file:
initial.png, 14523kb

ThomasDESOZA

Claws wrote:
Time [s]:

Constraine: 2337.87

Continue: 989.09

GCP: 2114.19

Lagrangien: 2318.58

Penalisation: 1080.75

Great news ! Thanks for the feedback, this is not that often that the CONTINUE method beats all the other and we're glad to hear about it.

Claws wrote:
Deformation can be seen the following two pics (order is the same as above) - notably the penalisation and continue deformation is 'weird' for a lack of a better word, probably a mistake on my part? Those two also completes in half the time of the other formulations.

I think the deformation is strange because you're viewing a displacement filed for a 2D modelization. The problem is the third component of the displacement field in the CONTINUE method is known as LAGS_C : it is the contact pressure. However Salomé does not know about it and uses it as the displacement along z-axis (DZ) so that's why the deformation is wrong (you can see in lower left corner that the mesh is distorted because of that).

To avoid that you should only print the DX, DY components of the DEPL field.

The fact that the PENALISATION method yields strange deformation is likely due to the E_N value which should be increased to converge towards the same results as the other methods.

TdS

Claws

Thomas DE SOZA wrote:
Great news ! Thanks for the feedback, this is not that often that the CONTINUE method beats all the other and we're glad to hear about it.

I think the deformation is strange because you're viewing a displacement filed for a 2D modelization. The problem is the third component of the displacement field in the CONTINUE method is known as LAGS_C : it is the contact pressure. However Salomé does not know about it and uses it as the displacement along z-axis (DZ) so that's why the deformation is wrong (you can see in lower left corner that the mesh is distorted because of that).

To avoid that you should only print the DX, DY components of the DEPL field.

The fact that the PENALISATION method yields strange deformation is likely due to the E_N value which should be increased to converge towards the same results as the other methods.

TdS

Actually, remembering your advice on my metal forging study recent, I only print DX, DY when using the CONTINUE method to avoid LAGS_C, but the deformation remains strange.

For PENALISATION I have a E_T value of 1e5, I will try to double it or similar later, to see if it helps. Right now Im running a 3D quarter-model (with PENALISATION), and that wont finish for the next many hours :)

Regards,

Claus

bosman

Hi!

Further testing of the example I sent, shows that LISSAGE='OUI' does

not appear to cause any convergence issues when using the CONTINUE formulation,

but convergence issues when using the LAGRANGIEN formulation.

Regards!

B-O

tcdonley

Sorry for my late reply, but I wish to finally follow up on my earlier post in this thread.

By switching to the CONTINUE method of contact simulation, I was able to obtain convergence at much higher loads. As Bosman noted, this problem does go deep into the plastic range. Actually I'm quite surprised at how deep into the plastic range the simulation was able to converge.

While it might be of academic interest to seek convergence above the load given in this new example, this more than satisifes my need in my industrial research. The industrial problem I am dealing with is complicated by the presence of a small boss feature which is compressed under the applied load. As the boss collapses, new geometric non-linearities become important, and new contact zones are created as the sides of the boss collapse into the plate.

This simple example has allowed me to better understand that convergence problems in my industrial model are related to geometric problems in the model, and it helps to understand the practical limits of simulation of contact with plastic deformation and friction.

I'm grateful for the many insights provided by all.

Attached are model files for the round tip contacting the aluminum plate, which undergoes plastic deformation. The PRES_REP specified is roughly the upper limit of convergence. I hope the example will be of use to someone else.

Best regards to all,

Tim Donley

Attached file:
contact_continue.tar, 102400kb

tcdonley

...And so you don't have to run the study to see the result, here is an image of the deformed mesh and DY values from Salome, with scale factor of 1 for the solution using the CONTINUE method in 10.3.

- Tim

Attached file:
contact_continue.jpg, 89399kb

ArchibaldArchambaud

Hi Tim.

This is a nice feedback regarding the huge work that has been done on the contact algorithms in Aster. Some major changes are still on the run for the "CONTINUE" method.

Thank you to all the people who contributed to this thread!

ThomasDESOZA

bosman wrote:
Hi!

Using LAGRANGIEN formulation for both contact and friction is causing convergence problems

in 10.3, but the same model runs fine in 10.1. I have a previous report on this here

http://www.code-aster.org/forum2/viewtopic.php?id=13539 for an axisymmetric problem.

Recently I have been testing this for a simple 2D plain strain model and basically getting the

same convergence problems. The model consist of a square block on top of a larger block

and the smaller block is moved a certain distance and then back. In 10.1 I get good convergence

and in 10.3 I get convergence but not as quick. The interesting observation is that

I get severe convergence problems with LISSAGE='OUI' in 10.3 but no real problems in 10.1.

I have gone back and reran the test I supplied in the previous post and get the same convergence problem

in 10.3 but not in 10.1 for the LAGRANGIEN formulation for both contact and friction.

In version 11.0.26 we fixed (at last) the remaining problem that arised after having transitioned to DEFI_CONTACT. I do not have a 10.1 version at hand so I did not check if in your particular case, things are now back to normal. However the tests' database shows that for problems using LAGRANGIEN for contact and friction solution time has been greatly decreased.

Regarding the issue with LISSAGE we did not look into it.

TdS