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

You are not logged in.

#1 Re: Code_Aster usage » Unknown operator: LIAISON_SOLIDE_SPH » 2023-01-04 16:53:50

Hello,

I don't know these commands. They were developed by someone else in the community and I have no information on the subject.

Sorry

#2 Re: Code_Aster usage » CODE ASTER Citation » 2022-12-12 23:58:58

Hello,

Strange request !
Do you use code_aster in another field than science or engineering ?

#3 Re: Code_Aster usage » Unknown operator: LIAISON_SOLIDE_SPH » 2022-12-10 18:10:05

Hello,

CALC_CHAMP with this syntax, LIAISON_SOLID_SPH and IMPR_FONC_MULT are not part of code_aster standard commands.

#5 Re: Code_Aster usage » TETRA4 - Finite elements taking into account incompressibility » 2022-11-26 22:37:35

In the uses of EDF, having a very good precision of the stresses  is essential.
This is not necessarily the case for forming problems (such as stamping), we are more interested in the global force for example and in the kinematics.
Nevertheless, it is possible to have linear elements in incompressible formulation, for example INCO_UP or INCO_UPO instead of INCO_UPG.

#6 Re: Code_Aster usage » TETRA4 - Finite elements taking into account incompressibility » 2022-11-25 23:38:22

Hello,

UPG formulation require quadratic approximation. The TETRA4 is only linear



As a general rule, when doing plasticity, it is always better to use quadratic elements

#7 Re: Code_Aster usage » meaning of FACE_IMPO DTAN » 2022-11-23 14:11:45

Hello,

MODELISATION='C_PLAN', 'D_PLAN', 'AXIS' => 2D (skin element are edges)

DTAN is only one value. You must have two in 3D (skin elements are 2D) => you cannot use DTAN is MODELISAITON='3D'

#8 Re: Code_Aster usage » Sugestion to improve documentation translation (with deepl). » 2022-11-22 22:50:11

Hello,

Same answers ...
BUt ...
We are starting to transfer our historical documentation (odt => pdf format) to a new, more modern format (markdown/rst in sphinx).
Which should make things easier for the open source community.
For people who follow the latest versions, they must have seen the documentation of the new Python methods in the source.

#9 Re: Code_Aster usage » hotspots in plate stress, when plates are glue-connected » 2022-11-20 17:15:59

Hello,

The FORMULATION='DISCRETE' is not recommanded

Use:
FORMULATION = 'CONTINUE'
ALGO_CONT='PENALISATION'
GLISSIERE='OUI'

NB: from a theroertical point of view a very large friction coefficient is not equivalent to clamped boundary condition (and it's not a good idea for convergence and ther is no unicity of solution)

#10 Re: Code_Aster usage » hotspots in plate stress, when plates are glue-connected » 2022-11-20 13:51:21

jacob wrote:

Hello,
sorry that I write something little off topic, but I wonder why there isn't actual GLUE contact in code aster, meaning contact with penalization, but both in compression and tension. It shouldn't be so hard to program since common contacts are already there. It would be nice alternative to bonded connection as LIAISON_MAIL, which is done with constraint equations.

Hello

"bilateral" contact => GLISSIERE = 'OUI' ?

#12 Re: Code_Aster usage » strange » 2022-11-02 09:08:03

I am in direct contact with Jean-Pierre.
We don't know what happened, certainly an automatic blacklist. We can't understand or correct

#13 Re: Code_Aster usage » strange » 2022-11-01 16:38:36

Hello,

Technical problem I think.
No one can ban Jean-Pierre from the forum. I have nothing in the administration interface in any case.

#14 Re: Code_Aster usage » Modal analysis results CA vs Abaqus » 2022-10-31 13:02:15

Hello,

DKT ?
No interest in under-integrating this kind of finite element. In general, one under-integrates to try to reduce certain numerical locks (like incompressibility). The fact that they are "less expensive" is a consequence, not an objective.
The DKT are elements of plates which use an assumption of plane stresses, do not lock or very little

#15 Re: Code_Aster usage » Modal analysis results CA vs Abaqus » 2022-10-29 23:20:13

traemand wrote:
mecour wrote:

Hello,

this is really stupid. Doing comparison of some result, without knowledge of element type.  Ansys usually use quadratic elements or combination of quadratic and linear element as default.  So if do not provide meshes which you use in your simulation, how somebody can tell where is the problem?!

For me this is the problem of salome-meca, ansys workbench and other user friendly  FEA guis. Everybody click fast his simulation without good knowledge of FEM or mechanics. 
Maybe I am old, sorry.

mecour

This is a bad attitude towards beginners, trying to get into this great piece of open source software. Please reconsider your attitude. This community needs more users, of all levels. Don't scare them away with elitist attitudes.

You're right !

Please, everyone, try to be kind !

A mistake from myself, I forgot to validate my previous post.

To use underintegrated elements, you can use 3D_SI instead of 3D in AFFE_MODELE/MODELISATION
For instance;
HEXA20 => 3D => 20 integration points
HEXA20 => 3D_SI => 8 integration points
HEXA8 => 3D => 8 integration points
HEXA8 => 3D_SI => 1 integration points with hourglass control

#16 Re: Code_Aster usage » Execution time of CALC_CHAMP » 2022-10-28 12:55:09

Hello,

Some estimations

88252 DOF
60000 time increment
Number of cells
POU_D_T       _                SEG2         MECA_POU_D_T     1239
DST              _                QUAD4        MEDSQU4          5667
DST              _                TRIA3        MEDSTR3          14316

One real is 8 bytes

Total for EFGE_ELNO
1239*2*6 * 60000 * 8 + 5667*4*6 * 60000 * 8 + 14316*3*6 * 60000 * 8 = 182 Go

Total for EFGE_NOEU
88252*60000*8 = 39 Go

To compute EFGE_NOEU, you need EFGE_ELNO before


Conclusion ?

#17 Re: Code_Aster usage » Modal analysis results CA vs Abaqus » 2022-10-28 08:12:47

Hello,

Of course, code_aster uses a complete integration, why use bad elements?

#18 Re: Code_Aster usage » [SOLVED]Control of the time increments in a THER_NON_LINE analysis » 2022-10-24 21:50:48

Hello,

Absolutely, there isn't any time adaptation in thermics.
The most efficient way in this case is to use line search

#20 Re: Code_Aster usage » Really slow analysis with contact » 2022-10-09 14:14:24

Hello,

FORMULATION='DISCRETE'
=> not efficient for parallel computation
Prefer use FORMULATION='CONTINUE'

Comaprison with commercial solvers is dfficult: it depends on machine installation of MPI for instance

#21 Re: Code_Aster usage » [SOLVED]LIAISON_MAIL in AFFE_CHAR_MECA » 2022-10-06 10:08:01

Hello,

Theory ?
Kinematic relation between DOF by orthogonal projection (master/slave).
Multi-Point Constraint in strong form

#22 Re: Code_Aster usage » my new book "Beginning DYNAmics with code_aster" is available » 2022-09-18 13:05:14

Hello Jean-Pierre,

You can try ARxiv or HAL for publish your book

#23 Re: Code_Aster usage » contact - quadratic mesh » 2022-09-12 16:53:00

Hello,

For FORMULATION=' DISCRET' and FORMULATION=' CONTINUE' the problem with elements QUAD8 on the surface is the same one: as the shape functions of these elements are NOT positive, the efforts of contact can oscillate of a node with another.
By doing INTEGRATION="GAUSS" instead of INTEGRATION="NOEUD", one can have better results in FORMULATION='CONTINUE', because one obtains an approximation of the mortar methods. But it doesn't always work.
Using QUAD9 (or TRIA6) is the best solution.
Only the LAC-type mortar-P0 method does not have this problem

#24 Re: Code_Aster usage » [SOLVED] Rayleigh damping in DYNA_NON_LINE » 2022-09-01 09:45:34

Hello,

In material properties
DEFI_MATERIAU/ ELAS / AMOR_ALPHA / AMOR_BETA