Welcome to the forums. Please post in English or French.

You are not logged in.

#1 Code_Aster usage » Contact / DIST_APPA » 2020-07-01 16:54:46

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

#2 Code_Aster usage » Contact simulation / meshing » 2020-06-29 23:16:36

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

#3 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-18 17:24:02

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?

#4 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-17 18:37:17

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.

#5 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-11 09:22:57

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.

#6 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-11 07:32:31

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.

#8 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-10 21:54:25

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?

#9 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-05 11:36:35

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.

#10 Re: Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-05 07:55:09

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

#11 Code_Aster usage » Metal forming simulation: contact volume / rigid surface » 2020-06-04 05:52:21

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

#12 Re: Code_Aster installation » [Solved] Compiling MPI version with PETsc on Ubuntu 18.04 » 2020-06-03 16:24:22

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.

#13 Re: Code_Aster installation » [Solved] Compiling MPI version with PETsc on Ubuntu 18.04 » 2020-06-03 15:05:00

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

#14 Re: Code_Aster installation » [Solved] Compiling MPI version with PETsc on Ubuntu 18.04 » 2020-06-03 11:14:29

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...

#15 Code_Aster installation » [Solved] Compiling MPI version with PETsc on Ubuntu 18.04 » 2020-06-02 17:11:40

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