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

You are not logged in.

- Topics: Active | Unanswered

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

Hello,

Strange request !

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

Hello,

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

Hello,

NOM_CMP='V' => NOM_CMP='DX' ?

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.

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

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'

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.

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)

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' ?

Say no to drugs

We don't know what happened, certainly an automatic blacklist. We can't understand or correct

Hello,

Technical problem I think.

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

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

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

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 ?

Hello,

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

Hello,

Absolutely, there isn't any time adaptation in thermics.

The most efficient way in this case is to use line search

AFFE_CARA_ELEM / MASS_REP ?

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

Hello,

Theory ?

Kinematic relation between DOF by orthogonal projection (master/slave).

Multi-Point Constraint in strong form

Hello Jean-Pierre,

You can try ARxiv or HAL for publish your book

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

Hello,

In material properties

DEFI_MATERIAU/ ELAS / AMOR_ALPHA / AMOR_BETA