Forming simulation of a tube II [SOLVED]

Johannes_ACKVA

Hello

I share several files of Code-Aster runs for a forming simulation of a tube. Very long CPU-times are needed with friction. I m searching and asking how to make it faster.

The circular tube is meshed in it's thickness direction with 2 layers of HEXA8 elements (I m aware of the low precision of these elements in shear). The axial direction is Y. The tube is pushed in it's axial direction versus a cylindrical cone (tool). The cone is rigid (MODELISATION='3D' applied on a surface mesh and all nodes of the surface are fixed (AFFE_CHAR_CINE). The cone's radius increases in Y-direction, so the tube gets in contact with the cone and is widened to the increasing radius of the tool. The cone's length is 0.12, the tube's length 0.4. The final enforced displacement of the tube is s=v*T=0.05*10=0.5, so very large displacements and sliding! Plasticity (VMIS_ISOT_TRAC), contact (CONTINUE) and friction are taken into account. >20pct of total plastic strain (VARI_ELGA, V1) are reached at the final displacement. The problem is axialsymmetric. But MODELISATION='3D' is applied because later the tool will be non-symmetric.

7 Code-Aster runs are attached, all for the same ridiculous very small partial mesh: an angular segment of 3degrees “width”, where the tube is made from 80 HEXA8 elements:

no friction:

(1) STAT_NON_LINE, no friction, DEFI_CONTACT with “Full-Newton”

(2) STAT_NON_LINE, no friction, DEFI_CONTACT with “FixPoint” for Contact and Geometry

(3) STAT_NON_LINE, no friction, DEFI_CONTACT with “FixPoint” for Contact and Geometry and GLISSIERE='OUI'

(4) STAT_NON_LINE, no friction, DEFI_CONTACT with “FixPoint” for Contact and Geometry and TOLE_APPA=0.02

with friction:

(5) non included because unintentionally deleted: STAT_NON_LINE, one contact slave zone comprising the complete length of the tube inside surface

(6) STAT_NON_LINE, 5 contact slave zones being length sections of the tube. 5 x DEFI_CONTACTs and 5 x STAT_NON_LINE (4 of which are reuse i.e. restarts) in order to consider only those nodes as contact slave nodes which are actually in correspondence to the tool (cone)

(7) DYNA_NON_LINE, as TOBI: http://code-aster.org/forum2/viewtopic.php?id=20839, but with SCHEMA_TEMPS=_F(SCHEMA='NEWMARK')

CPU-times are:

no friction

(1) 249.56

(2) 59.09

(3) 49.42

(4) 59.29

with friction

(5) 8678.35

(6) 6944.67

(7) 7897.95

I have several ideas or questions how to improve the performance of “with-friction”:

(a) Full-Newton versus FixedPoint in DEFI_CONTACT:

Comparision between (1) and (2) points to FixPoint-method to be better. That's why I continued all examples with friction using FixPoint-method. Which is known to be slower but more robust. At the end (due to robustness) it is here faster.

I have doubt if the Full-Newton method would converge with friction (until now bad experiences)

(b) REAC_GEOM = 'CONTROLE', NB_ITER_GEOM=1

This reduces CPU-time to about 50pct! About the loss of precision (which I hope is not too bit) read here:

http://code-aster.org/forum2/viewtopic.php?id=21219

(d) DEFI_CONTACT(..GLISSIERE..)

I had no experience so far with this parameter . Here (no friction) it has no effect (compare (2) and (3)). I thought it should save CPU-time since the freedom of the model is restricted. Can anybody judge if this could/would be promising for a case with friction?

(e) DEFI_CONTACT(..TOLE_APPA=0.02..)

same remark as in (d). Compare (2) with (4) shows no effect. Can anybody judge if this could/would be promising for a case with friction?

(f) LAC-contact (in the unstable Code-Aster version)

seems not promising because has no friction and not very suited to nonlinearity, see here

http://code-aster.org/forum2/viewtopic.php?id=21066

(g) Criterion for too large residuals in DEFI_LIST_INST

http://code-aster.org/forum2/viewtopic.php?id=19811

https://bitbucket.org/code_aster/codeaster-src/issues/35

I hope in this. The most frequent reason for is a problem with the integration of the nonlinear material. It appears mainly when there is friction, perhaps due to friction-caused shear:

“Échec dans l'intégration de la loi de comportement”

(h)

generally, my impression is that friction (here coefficient=0.1) can be handled in a robust manner with the FixPoint-Method, but with very very huge CPU-times (>100 x as long as without friction)

(i) How to solve “Échec dans l'intégration de la loi de comportement”?

That's my main sorrow. Because it seems that the time step will be cut down to infinitely small... Is there something to ameliorate this situation?

Many thanks for any helpful discussion,

Regards Johannes_ACKVA

__________________________________________________________________

next CODE-ASTER-courses at Ingenieurbüro für Mechanik, Germany

*** CODE-ASTER INTRO + CONTACT + MATERIAL

16-20 January 2017

*** CODE-ASTER DYNAMIC ANALYSIS

16-17 February 2017

Attached file:
TubePlasticForming_no-friction_ToForum.zip, 1393998kb

Johannes_ACKVA

further attachment

Attached file:
TubePlasticForming_with-friction_ToForum.zip, 650737kb

Johannes_ACKVA

further attachment

Attached file:
TubePlasticForming_meshs_ToForum.zip, 202938kb

RichardS

Hello Johannes,

I have you done a comparison using ALGO_RESO_FROT='NEWTON' together with ADAPT_COEF='OUI'?

In my experience this is the best solution for friction.

Best,

Richard

TOBI

Hello Johannes,

Hello everybody,

this is really amazing! I think we actually work on a really similar topic and fight with the same problems.

Your informations, models, remarks and questions are really interesting. Unfortunately after a really busy year I take a break over Christmas and go on holiday after Christmas until 16.1.2017. So I cannot view all your models in detail now. I will do this, when I be back in January. But today in short I will share some informations with you, that might be interesting.

First I'm sorry, but you didn't view the latest version of my model. I have attached an actual version. I know at the moment the mesh is really coarse, it's only for testing.

In my opinion (as RichardS also said), it is the best option to set all ALGO_RESO_* to NEWTON and ADAPT_COEF='OUI'.

As you can see, at the moment I also work with STAT_NON_LINE. At the beginning I had convergence problems with STAT_NON_LINE and switch to DYNA_NON_LINE, the choice of Hughes-Hilber-Taylor-Scheme (HHT) was a little bit random because I know it good from other applications and had no experience with newmark.

After locking all rigid body motions and setting SEUIL_INIT=1.0e5 I go back to STAT_NON_LINE, which makes the simulation a little bit faster.

“Échec dans l'intégration de la loi de comportement” and a really small time-step (smaller 1.0e-3) was also my main problem at the beginning. As you can see in the MESS-File, this problem is solved.

The solution for me was setting ALGO_FROT='PENALISATION', ALGO_CONT='PENALISATION', and SEUIL_INIT=1.0e5. Now I'm really happy, the time step is mostly 5.0 (Simulation-Time=200). In my opinion this is a well approach and it's also referenced to literature. For example the book "FEM-Formelsammlung (Nasdala, L.) says, that the penalty-method is the best solution for contact with friction. The augmented-lagrange method (ALGO_FROT='STANDARD', ALGO_CONT='STANDARD',) is described as time expensive and unstable, but of course highly accurate. So in my opinion it's more suited for smaller problems, that needs a high accuracy!? The time step is going to be a little smaller with quadratic mesh!!

The only disadvantage is, that one has to set the penalty-stiffness, what is try&error at the moment! The good news are, that the penalty stiffness didn't affect the calculation-time so much, maybe because the master surface is rigid!? At the moment most of the times I find an approach with the youngs modulus (e.g. Cp=E/l, where l is characteristic lengths of the surface-mesh). But mostly this leads to a stiffness which is to high. A more accurate solution might be an approach with the highest entry in the stiffness-matrix, I will try next year.

At the end I hope, that my model and my insights helps you and will be excited about your feedback.

I read the post you linked about LAC-contact. Now I'm not sure if it is well suited for our problem!? Until now I didn't get it working on an own model. Maybe it would be better to work with the common methods this time.

At the moment my main sorrow is, that there are only really limited possibilities to do a forming simulation with shells. I have some problems in sheet metal forming in 2017 that are to big for modelling in 3D. Because of the lack of double sided contact and large strain I cannot model them with COQUE_3D. One solution could be here (at the end), but only small strain: http://code-aster.org/forum2/viewtopic.php?id=20839

I will be back in January with some test results on your remarks.

Wish you all merry Christmas and a happy new year

TOBI

Attachmet (first time failed)

Attached file:
Umformen_Forum.zip, 53386kb

TOBI

Mesh Tube

Attached file:
RohrHex_Lin.med.zip, 87060kb

TOBI

Sorry, cannot upload tools, data size is to big!

But I think everything it's self-explanatory with the COMM-File!??

TOBI

Johannes_ACKVA

hello,

I had some success to make the analysis faster

case (8):

STAT_NON_LINE,

one contact slave zone comprising the complete length of the tube inside surface (as case (5)),

ALGO_RESO_CONT='NEWTON',

ALGO_RESO_FROT='NEWTON' with ADAPT_COEF='OUI'.

Switched to the newer version CodeAster11.3 because of the new

DEFI_LIST_INST(ECHEC=( _F(EVENEMENT='RESI_MAXI',..)..)

CPU-time:

(8) 1435.05

Since from case (5) to (8) more than 1 parameter has been changed, the single effects can only be estimated: From the time lost in useless loops (dont temps CPU "perdu" dans les découpes) I estimate that ECHEC=( _F(EVENEMENT='RESI_MAXI',..) made the analysis about 40pct faster. The other performance improvement must be due to the "full newton" approach and ADAPT_COEF='OUI'

Thank you RichardS and TOBI !

I will try next penalty contact as TOBI proposes.

Regards Johannes_ACKVA

__________________________________________________________________

next CODE-ASTER-courses at Ingenieurbüro für Mechanik, Germany

*** CODE-ASTER DYNAMIC ANALYSIS

16-17 February 2017

TOBI

Hello,

thank you for the update, sounds all good!

Some of my analysis also run much faster with REAC_GEOM = 'CONTROLE', NB_ITER_GEOM=1 and FixPoint for geometry.

At the moment I'm running the same model with REAC_GEOM = 'CONTROLE', NB_ITER_GEOM=1 and REAC_GEOM = 'AUTO..', to check the influence. I will post the results.

One Question about DEFI_LIST_INST(ECHEC=( _F(EVENEMENT='RESI_MAXI',..)..)

I cannot find this option in the documentation. Is it new in 13.3? Where can I find informations about it? Can you attach a COMM-file or post a piece of code about it? That would be perfect.

Regards TOBI

Johannes_ACKVA

TOBI, syntax is here

http://code-aster.org/forum2/viewtopic.php?id=19811

Only from version 11.3

Regards Johannes_ACKVA

__________________________________________________________________

next CODE-ASTER-courses at Ingenieurbüro für Mechanik, Germany

*** CODE-ASTER DYNAMIC ANALYSIS

16-17 February 2017

konyaro

Hello Johannes,

I plaid a bit with your model. A faster configuration turned out to be simply:

c000_040 = DEFI_CONTACT(MODELE = model,

LISSAGE = 'OUI',

FROTTEMENT = 'COULOMB',

FORMULATION = 'CONTINUE',

ALGO_RESO_GEOM='POINT_FIXE',

ALGO_RESO_FROT='NEWTON',

ALGO_RESO_CONT='NEWTON',

REAC_GEOM = 'CONTROLE',

ADAPT_COEF='OUI',

NB_ITER_GEOM=2,

ZONE = (_F(GROUP_MA_MAIT = 'master',

GROUP_MA_ESCL = 'c000_040',

ALGO_CONT='PENALISATION',

ALGO_FROT='PENALISATION',

COEF_PENA_CONT=4.0e11,

COEF_PENA_FROT=4.0e8,

COULOMB=0.2,),),);

I usually don’t use the ‘STANDARD’ lagrangian contact for friction because tangential forces tend to be too high. A small penetration with the penalisation tend to smooth the contact.

I didn’t try the full Newton resolution because I was sure it wouldn’t converge but actually it did in your case…

May I ask you a question: why is it possible to use 3D elements for your cone which is made of 2D elements?

Regards,

Konyaro

Johannes_ACKVA

thank you, Konyaro

Konyaro wrote:
why is it possible to use 3D elements for your cone which is made of 2D elements?

I m not shure to understand your question well. The cone is made of 2D elements, the tube of 3D elements. The cone could be made of 3D (with a 2D-skin as contact group), but in that case the MODELISATION='3D' must be affected /applied only the the 3D-tube, 2D-skin of the tube (cnt slave) and 2D-skin of the cone (cnt master). Please ask again if I misunderstood you

I have some more questions:

Konyaro, what do you mean by "the full Newton resolution"? The "fullest" would be ALGO_RESO_GEOM='NEWTON', ALGO_RESO_FROT='NEWTON',ALGO_RESO_CONT='NEWTON', is it? So you did not use it. In your experience, is the "fullness" which you used (ALGO_RESO_GEOM='POINT_FIXE', ALGO_RESO_FROT='NEWTON',ALGO_RESO_CONT='NEWTON') together with ADAPT_COEF='OUI' the robustest solution? I have sorrows because later I will have to simulate more difficult cases (due to stronger distorted elements)

is the penalty method for friction faster in particular if there a big friction values? Konyaro, I see you used COULOMB=0.2 getting a fast solution. I have used always COULOMB=0.1 because bigger values slowed down to much

question regarding ADAPT_COEF

http://code-aster.org/forum2/viewtopic.php?id=21429

Regards Johannes_ACKVA

__________________________________________________________________

next CODE-ASTER-courses at Ingenieurbüro für Mechanik, Germany

*** CODE-ASTER DYNAMIC ANALYSIS

16-17 February 2017

konyaro

Hello Johannes,

I asked the question of the 2D elements because you use:

_F( PHENOMENE = 'MECANIQUE', TOUT = 'OUI', MODELISATION = '3D', ): I thought that as you use TOUT='OUI' the ‘3D’ modelisation would be assigned also to the 2D shell elements of the cone. Now I understand that the '3D' applies only to 3D elements even with TOUT='OUI' and no modelisation is applied to the 2D shell elements of the cone, is this assumption correct?

* Yes, by full Newton I mean: (ALGO_RESO_GEOM='NEWTON', ALGO_RESO_CONT='NEWTON', ALGO_RESO_FROT='NEWTON'). This method is great in theory but convergence often turns out to be very difficult. The best compromise (robustness and speed) I found until now is indeed: (ALGO_RESO_GEOM='POINT_FIXE', ALGO_RESO_CONT='NEWTON', ALGO_RESO_FROT='NEWTON'). I’m not sure that ADAPT_COEF='OUI’ does anything with a penalty contact as it does adapt the COEF_FROT but probably not the COEF_PENA_FROT… )

* I think a high friction value always makes the simulation slower… I used 0.2 which is for me quite a high value to see if I could obtain convergence.

* I guess the ADAPT_COEF changes the COEF_FROT for the whole zone therefore your question of splitting a zone is pertinent but I don’t have the answer!

Regards, Konyaro

Johannes_ACKVA

to complete and then close this thread I report here some more answers which I have found during the last months, also from kindly helpful collegues:

question regarding ADAPT_COEF:

(see also here: http://code-aster .org/forum2/viewtopic.php?id=21429)

ADAPT_COEF='OUI' changes the COEF_FROT value individually for each slave node, so there is no need to split a contact zone in several if there are more sliding and more adherent sub-regions (Konyaro)

comparision STAT_NON_LINE <--> DYNA_NON_LINE

DYNA_NON_LINE was always slower. And it seems logic just by the fact that there a 2 system matrices (M and K). So DYNA_NON_LINE has really only sense if it is a dynamic problem, or as a trial if the iteration table really sticks..

comparision PENALTY <--> CONTINUE contact

I confirm Penalty is general faster and easier to converge (TOBI). ADAPT_COEF='OUI' has no influence in the case of penalty contact (Konyaro).

REAC_GEOM = 'CONTROLE', NB_ITER_GEOM=1

is a very very powerful time-saver (compared to REAC_GEOM = 'AUTOMATIQUE'), with in practice general very low loss of precision.

See discussin here: http://code-aster. org/forum2/viewtopic.php?id=21219

Regards and good success to everybody !

Johannes_ACKVA

______________________________________________________________________

CODE-ASTER-courses at Ingenieurbüro für Mechanik, Germany

*** CODE-ASTER INTRO + CONTACT + MATERIAL

09-13 October 2017

*** CODE-ASTER DYNAMIC ANALYSIS

30 Nov - 01 Dec 2017

siyavash2005

I'm trying to re-create the simulation from the original post by Johannes_ACKVA. I've updated some of the keywords to meet the requirements of the new version of Code-Aster. If anybody know why the simulation here has convergence problems as opposed to the original which seems to have converged, your help would be much appreciated.

Below are the mesh, comm and mess files. Thanks!

Attached file:
TubeForming2018.zip, 211497kb