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

You are not logged in.

- Topics: Active | Unanswered

Pages: **1**

**hkroeger**- Replies: 0

Hi all,

I'm wondering how the DIST_APPA parameter should be understood.

The doc says (If I understand the "english" right), that only elements within a sphere with the prescribed radius around a slave node are candidates for pairing.

Do the elements have to be entirely inside the sphere? (Then DIST_APPA should be larger than some typical cell size)

Or is it sufficient, that the intersection point between normal and master face is closer than DIST_APPA?

Thanks for comments.

Regards

**hkroeger**- Replies: 0

Hi all,

I have a question regarding the meshing of contact surfaces:

If a master surface is rigid, i.e. all nodes have fixed displacements, is it then ok to split the mesh into parts which are geometrically adjacent but not meshes conformally? Or do I have to expect convergence problems in this case?

Regards

hkroeger wrote:

I guess, this is because PENTA elements don't have midnodes on their triangular sides?

Ok, I see that this is true ( u3/u3.01.00.pdf ).

Is it then a problem to have these triangular sides in a contact surface?

I'm still working on optimizing my mesh (minimizing mesh resolution and retaining sufficient quality).

Currently, I'm trying quadratic surface mesh (rigid) for the mold and quadratic PENTA elements for the workpiece (originating from an extrusion of a triangular surface mesh).

The "Instructions for the use of contact" say, that quadratic PENTA elements should be converted to those with midnode, i.e. CREA_MAILLAGE / PENTA15_18:

```
mesh1 = CREA_MAILLAGE(MAILLAGE=mesh0,
PENTA15_18=_F(GROUP_MA=('Grbl_Volumes', 'Grbl_Faces'),
PREF_NOEUD='NS',
PREF_NUME=1,),
INFO=1,)
```

It is not fully clear to me, how the surface elements should be treated. As you can see, I included also the face element group (Grbl_Faces) and thought that the TRIA6 faces (which make up the contact surface) should be converted into TRIA7 ones also. But that does not seem to be the case. Only QUAD8 on the side are turned into QUAD9. I guess, this is because PENTA elements don't have midnodes on their triangular sides?

The other question: the opposite contact side are (rigid) TRIA6 faces. Should those be explicitly converted into TRIA7's as well?

Thanks for any hint.

Thanks for the link. I have already seen and read this thread.

The conclusion was, that penalty method works best. I also tried to apply the penalty method (with and without friction) to my case but this was not successful and led to divergence.

I also observed some issues with ever ongoing oscillations of contact residuals, which I tried to resolve with REAC_GEOM = 'CONTROLE'. This worked sometimes but led to divergence in other cases. One should use a high number of load steps together with this option probably.

Hi sameer,

thanks for your comment.

I tried gmsh in the beginning. But I was not satisfied with the automatic adaption of mesh size to curvature. I wanted to have most resolution at the rounded bumps whereas there are also larger plane areas, which I wanted to resolve with only the least number of elements.

In gmsh, only the faces curved in 2 axes were refined whereas the 1 axis curved, cylindrical faces got only a very coarse resolution.

Netgen does a better job here and needs much less user input (manually selecting faces or points was no option for me with this geometry).

My experience with friction on this example is, that things only get worse. I had this idea as well, but it did not improve.

and the other image

Ok, I understood now, that it is apparently the right way to assign modelling '3D' to the facet elements that I would like to be rigid. I could made it work for both linear and quadratic elements. The errors concerning the normals seemed to be related to non-convergence and excessive deformations.

So far my experience is, that many linear facets work better than fewer quadratic. But maybe this is also related to some limits of the mesher (netgen in my case), which cannot produce the coarser with a sufficient quality.

Now I observed one thing, which I don't understand. Maybe someone can give me a hint: At first, I applied the displacement of the mold via AFFE_CHAR_CINE to keep the linear equation system size at a minimum. I applied this to all nodes of the upper mold part (modelled rigid) and expected to see exactly the prescribed displacment everywhere. Suprisingly this was not the case. I see some spots, where some different displacements are observed: see attached affe_char_cine.png.

When I switch to AFFE_CHAR_MECA without changing anything else, this problem disappears and the displacement is uniform everywhere (see attached affe_char_meca.png).

Moreover, the contact convergence is affected. The former case shows a higher CONTACT CRITERE VALEUR (everything else is identical) and has problems with contact convergence:

```
Instant de calcul: 5.000000000000e-02 - Niveau de découpe: 1
-----------------------------------------------------------------------------------------------------------------------------------------
| CONTACT | NEWTON | RESIDU | RESIDU | OPTION | CONTACT | CONTACT | CONTACT |
| BCL. GEOM. | ITERATION | RELATIF | ABSOLU | ASSEMBLAGE | NEWTON GENE | PRESSURE | CRITERE |
| ITERATION | | RESI_GLOB_RELA | RESI_GLOB_MAXI | | VARI. CONT. | ERROR | VALEUR |
-----------------------------------------------------------------------------------------------------------------------------------------
| 1 X | 0 X | 3.54556E+02 | 1.44965E+03 X |TANGENTE | 1425 X | 1.47871E+00 | |
| 1 X | 1 X | 4.40752E+00 | 1.85245E+03 X |TANGENTE | 534 X | 1.25022E+00 | |
| 1 X | 2 X | 5.85354E-01 | 1.92612E+02 X |TANGENTE | 162 X | 3.84837E-01 | |
| 1 X | 3 X | 3.70102E-01 | 1.13027E+02 X |TANGENTE | 29 X | 3.02454E-02 | |
| 1 X | 4 X | 3.67499E-02 | 1.12101E+01 X |TANGENTE | 5 X | 8.62974E-04 | |
| 1 X | 5 X | 1.32510E-02 | 4.04202E+00 |TANGENTE | 1 X | 6.46025E-05 | |
| 1 X | 6 | 6.21705E-03 | 1.89643E+00 |TANGENTE | 0 | 2.16557E-05 | 1.00000E-01 |
-----------------------------------------------------------------------------------------------------------------------------------------
| 2 X | 0 X | 1.90270E+02 | 2.08851E+03 X |TANGENTE | 152 X | 9.88986E-01 | |
| 2 X | 1 X | 4.93703E-01 | 2.78437E+02 X |TANGENTE | 129 X | 9.39207E-01 | |
| 2 X | 2 X | 6.49786E-02 | 2.00579E+01 X |TANGENTE | 22 X | 5.40369E-02 | |
| 2 X | 3 | 8.92909E-03 | 2.71580E+00 |TANGENTE | 0 | 5.71136E-04 | 4.24256E-01 |
-----------------------------------------------------------------------------------------------------------------------------------------
```

and the latter case:

```
Instant de calcul: 5.000000000000e-02 - Niveau de découpe: 1
-----------------------------------------------------------------------------------------------------------------------------------------
| CONTACT | NEWTON | RESIDU | RESIDU | OPTION | CONTACT | CONTACT | CONTACT |
| BCL. GEOM. | ITERATION | RELATIF | ABSOLU | ASSEMBLAGE | NEWTON GENE | PRESSURE | CRITERE |
| ITERATION | | RESI_GLOB_RELA | RESI_GLOB_MAXI | | VARI. CONT. | ERROR | VALEUR |
-----------------------------------------------------------------------------------------------------------------------------------------
| 1 X | 0 X | 3.44914E+00 | 1.44965E+03 X |TANGENTE | 1425 X | 1.47871E+00 | |
| 1 X | 1 X | 5.30009E+00 | 1.85245E+03 X |TANGENTE | 534 X | 1.25022E+00 | |
| 1 X | 2 X | 6.30701E-01 | 1.92612E+02 X |TANGENTE | 162 X | 3.84837E-01 | |
| 1 X | 3 X | 3.70535E-01 | 1.13027E+02 X |TANGENTE | 29 X | 3.02454E-02 | |
| 1 X | 4 X | 3.67499E-02 | 1.12101E+01 X |TANGENTE | 5 X | 8.62974E-04 | |
| 1 X | 5 X | 1.32510E-02 | 4.04202E+00 |TANGENTE | 1 X | 6.46025E-05 | |
| 1 X | 6 | 6.21705E-03 | 1.89643E+00 |TANGENTE | 0 | 2.16557E-05 | 1.00000E-01 |
-----------------------------------------------------------------------------------------------------------------------------------------
| 2 X | 0 X | 3.70317E+00 | 2.08850E+03 X |TANGENTE | 152 X | 9.89021E-01 | |
| 2 X | 1 X | 8.73024E-01 | 2.78437E+02 X |TANGENTE | 129 X | 9.39236E-01 | |
| 2 X | 2 X | 6.59471E-02 | 2.00579E+01 X |TANGENTE | 22 X | 5.40428E-02 | |
| 2 | 3 | 6.44419E-03 | 1.95990E+00 |TANGENTE | 0 | 5.71159E-04 | 7.41189E-03 |
-----------------------------------------------------------------------------------------------------------------------------------------
```

Since my case is very large, I would like to keep the benefit in computational effort of AFFE_CHAR_CINE. Is there something I can do to remove the artifacts from the AFFE_CHAR_CINE-case?

This is the error about the normals, which I receive when I apply modelling type "3D":

```
!----------------------------------------------------------------!
! <EXCEPTION> <APPARIEMENT_16> !
! !
! Le vecteur normal résultant est nul au niveau du noeud N11822. !
! Erreur de définition de la maille ou projection difficile. !
!----------------------------------------------------------------!
```

It does not appear immediately, but after about half of the simulation steps.

Hi again,

I should probably describe my motivation a bit more detailed: I want to simulate a sheet metal forming process. There are several examples for that in the forum and I found these very helpful. I was able to create the attached input file file, which I tested on a smaller cutout of my full geometry and it works (attached).

The model uses linear facets for the molds and quadratic prisms for the sheet. Though there is some material and stiffness assigned, all DOFs of the mold surface are prescribed, so it shall behave essentially as rigid. This is how I saw it in most examples.

Now my problems are:

1.) with the linear facets, I sometimes observe oscillations in the contact residuals. As I understand, these may be observed, if the contact surface is too coarsely resolved. So I am forced to invest many elements to resolve the mold surface properly.

2.) the full problem is approximately 100x larger than the test cutout (and without any useful symmetry unfortunately). That leads to minimum 600k faces on each mold side. The case hardly fits into the memory of my machine (250G RAM + 250G swap) and runs very slowly (MPI parallel on 23 cores), probably due to swapping.

What I tried:

a) Using LAC contact and a coarser mold mesh: out of memory, even with the smaller mesh

b) setting the INTEGRATION parameter in contact: leads to non-convergence

c) switching to curved elements on the mold surface, thus reducing the number of elements and contact pairing search ops:

- when COQUE_3D modelling is assigned, I cannot use CONTINUE contact and DISCRETE contact produces a singular matrix. I guess the latter is either caused by the BCs specified on the molds' nodes or because I use plastic material law and that yielding a non-symmetric stiffness matrix (I deduced that from some remarks in the DEFI_CONTACT docs but I'm not sure that I understood everything right)

- when 3D modelling is assigned to the mold faces, I see error messages concerning the normals and I have no idea what causes them.

I would be very grateful to get some directions on what options I have in Code_Aster to modify the model such that it requires least ressources during the run.

Thanks!

Regards, Hannes

**hkroeger**- Replies: 10

Hi,

I found a number of examples for setting up contact problems up 3d volume elements with DKT (rigid) triangular surface meshes.

Now I would like to switch to curved quadratic elements and tried COQUE_3D elements in the first attempt. The solver tells me that it is then not possible to work with CONTINUE contact in that case.

Is there a way to use CONTINUE contact with curved surface meshes? (I mean, other than switching to volume meshes on the surface side. The meshing process is getting prohibitively slow in that case for my geometry)

Thanks for any hint!

Regards, Hannes

Yes, I used PETSc.

And sorry, there was a typo in my last message: it did *not* give me the expected speedup.

I have a large mesh with a big contact surface with many geometric details and I use CONTINUE for solving the contact.

When I used MUMPS, it needed half the time to factorize the equations and some modest amount of time for solving.

With PETSc, a similar amount of time is required for factorization and twice as much time (as factorizing) for solving.

I explain it to me so, that in my case, there is a benefit from reusing the stored factorization instead of iteratively solving the system over and over again.

Hi,

thanks for the valueable recipe in your dockerfile!

I did not run the tests.

But my actual Code_Aster case was running. Although, it did give me the speedup, I hoped for...

Regards, Hannes

Ok, I finally found a working solution here:

https hitoricae.com/2019/11/10/code_aster-14-4-with-petsc/

The check was simply patched out of the configure script...

**hkroeger**- Replies: 7

Hello everyone,

I'm currently having a hard time to build a parallel Code_Aster (14.4) version with PETsc (3.9.4).

Without PETsc everything is fine. I got inspired by tianyikillua's work (github.com/tianyikillua/code_aster_on_docker/blob/master/code_aster/Dockerfile).

But as soon as I try to include PETsc, I run into a number of problems:

1) I built parmetis with the following fix:

```
patch -s -p0 << EOF
diff -ruN parmetis/metis/include/metis.h parmetis_aster/metis/include/metis.h
--- parmetis/metis/include/metis.h 2013-03-30 17:24:50.000000000 +0100
+++ parmetis_aster/metis/include/metis.h 2019-04-29 13:43:58.000000000 +0200
@@ -30,7 +30,11 @@
GCC does provides these definitions in stdint.h, but it may require some
modifications on other architectures.
--------------------------------------------------------------------------*/
+#ifdef INTSIZE32
#define IDXTYPEWIDTH 32
+#else
+#define IDXTYPEWIDTH 64
+#endif
/*--------------------------------------------------------------------------
EOF
```

When I try to build PETsc, I get

```
UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details):
-------------------------------------------------------------------------------
Metis specified is incompatible!
IDXTYPEWIDTH=64 metis build appears to be specified for a default 32-bit-indices build of PETSc.
Suggest using --download-metis for a compatible metis
```

(The configure options were:

```
./configure --COPTFLAGS="-O2" \
--CXXOPTFLAGS="-O2" \
--FOPTFLAGS="-O2" \
--with-debugging=0 --with-shared-libraries=1 \
--with-scalapack-dir=${PUBLIC}/scalapack-${SCALAPACK_VER} \
--with-ptscotch-dir=${PUBLIC}/ptscotch-${SCOTCH_VER} \
--with-metis-dir=${PUBLIC}/metis-${METIS_VER} \
--with-parmetis-dir=${PUBLIC}/parmetis-${PARMETIS_VER} \
--LIBS="-lgomp" \
--prefix=${PUBLIC}/petsc-${PETSC_VER}
```

2) when I add "--with-64-bit-indices" to the configure options, PETsc builds, but problems with the aster build occur:

```
/home/hannes/code_aster/SRC/aster_mpi/bibfor/elim_lagr/elg_allocvr.F90:46:49:
call VecSetBlockSize(vect1, to_petsc_int(bs), ierr)
1
Error: Type mismatch in argument ‘b’ at (1); passed INTEGER(4) to INTEGER(8)
/home/hannes/code_aster/SRC/aster_mpi/bibfor/elim_lagr/elg_allocvr.F90:48:59:
call VecSetSizes(vect1, PETSC_DECIDE, to_petsc_int(n1), ierr)
1
Error: Type mismatch in argument ‘c’ at (1); passed INTEGER(4) to INTEGER(8)
```

My impression is, that CA relies on 32 bit integers with PETsc, as the header bibfor/include/asterf_types.h indicates, and switching to 64 bit indices is not the right way.

It is not fully clear to me, what the proper set of options for building the various dependencies is. Could someone give me a hint on what the intended configuration is (on a 64bit system)?

Thanks a lot in advance!

Regards, Hannes

Pages: **1**