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

You are not logged in.

#1 Re: Code_Aster usage » Non Convergence from shell to shell contact » 2020-09-08 07:05:20

Hello,
I'm not used to shell elements but re-orienting the contact surfaces leads to convergence. I also modified the contact in order to make it faster.

Konyaro

#3 Re: Code_Aster usage » <EXCEPTION> <COMPOR5_1> On ne trouve pas la courbe de traction » 2020-07-09 05:43:21

Hello,
you must add the 2 behaviors in STAT_NON_LINE:

COMPORTEMENT=(_F(GROUP_MA=('steel'),
                 RELATION='VMIS_ISOT_TRAC'),
              _F(GROUP_MA=('concr'),
                 RELATION='ELAS')),

Konyaro

#4 Re: Code_Aster usage » Advice needed on <EXCEPTION> <DVP_1> (DYNA_NON_LINE) » 2020-07-08 08:49:38

Hello,
your case runs fine. It requires a lot of RAM as there are many nodes and you're using a direct solver. I guess that's the source of your problem. The Windows version doesn't depict the memory error messages. You should try to increase the amount of memory or reduce the size of the mesh.

In the attached files I switched to larger linear elements and changed a few things in your comm file: GROT_GDEP, contact, reuse for CALC_CHAMP, less steps as I don't want to wait for hours. It does converge well.

Konyaro

#5 Re: Code_Aster usage » [Solved]Advice needed on <EXCEPTION> <FACTOR_78> (DYNA_NON_LINE) » 2020-06-27 06:47:20

So it bears the question: how do one obtain surfaces or edges in 3D?

You must create groups, not new elements. The easiest way is to use "Create groups from geometry" in the MESH module. If you select a face it will create a group of 2D elements, if you select an edge it will create a group of 1D elements.

Given that, should I use Netgen ONLY for meshing the ball? Or should I avoid using Netgen at all?

You can use whatever you want. If you don't know what to choose I recommend quadratic tetrahedrons.

Konyaro

#6 Re: Code_Aster usage » [Solved]Advice needed on <EXCEPTION> <FACTOR_78> (DYNA_NON_LINE) » 2020-06-21 06:14:36

Moreover be careful, you mesh has quadrangles only on the surface

I just wanted to point out that one may think that a Netgen mesh with the option "Quad-dominated" produces a nice hexahedral mesh. This is not the case, the elements are pyramids connected to tetrahedrons.
Fake Hexas

#7 Re: Salome-Meca usage » [SOLVED] Get shared nodes in solids with different mesh elements » 2020-06-20 05:51:46

Hello,
there are similar posts in the salome-platform's forum. It's a bit tricky, you must add 2 sub-meshes in order to apply 2 different algorithms:

Mesh

Konyaro

#8 Re: Salome-Meca usage » Von-Mises Stress in Salome-Meca » 2020-06-20 05:10:36

Hello,
you can simply calculate them after your analysis:

resu1 = CALC_CHAMP(reuse=resu1,
                    CRITERES=('SIEQ_NOEU'),
                    RESULTAT=resu1,
                    TOUT_ORDRE='OUI')

and you will be able to display the Von Mises stresses called VMIS.

Konyaro

#10 Re: Code_Aster usage » [Solved]Advice needed on <EXCEPTION> <FACTOR_78> (DYNA_NON_LINE) » 2020-06-20 04:57:02

Hello,
there are a few mistakes in your model and the main issue is that you're meshing solids AND faces. You must simply define groups in the geometry and not duplicate faces. Moreover be careful, you mesh has quadrangles only on the surface. I corrected a few points in your comm files, it's converging nicely.

Ball

Konyaro

#11 Re: Code_Aster usage » [Solved]Advice needed on <EXCEPTION> <CONTACT2_11> (DYNA_NON_LINE) » 2020-06-08 05:40:18

Hello,
as stated in doc U4.44.11 §3.1.2, your master and slave must be surfaces or edges in 3D.

Konyaro

#12 Re: Salome-Meca installation » salome-meca for windows Error: Can not save file » 2020-05-30 06:01:19

Have a look at:
www. salome-platform.org/forum/forum_10/541818275

#13 Re: Salome-Meca usage » [SOLVED] Sequential calculation - IMPORT RESULTS from previous stage » 2020-05-11 15:46:25

I would like to comment one detail i have seen in your example, why do you use AFFE_CHAR_CINE in Stage1 while you use AFFE_CHAR_MECA in Stage2?  Is there a hidden reason to do that? is it a technical reason?

AFFE_CHAR_CINE is faster but cannot be used with DIDI.

#14 Re: Code_Aster usage » Batch Code_Aster, lancer plusieurs calculs » 2020-05-11 08:14:01

Bonjour,
je n'arrive pas à lire le maillage créé avec ToAster(), j'obtiens l'erreur suivante:
"soit le fichier n'existe pas, soit c'est une mauvaise version de HDF (utilise par MED). "

Mon code est très simple:

DEBUT(PAR_LOT='NON', LANG='FR',)
from Utilitai import partition

mesh = LIRE_MAILLAGE(FORMAT='MED',
                       UNITE=2)

mesht = partition.MAIL_PY()
mesht.FromAster('mesh')
unite = mesht.ToAster()
mesh0 = LIRE_MAILLAGE(UNITE=unite)

FIN()

Toute aide est la bienvenue,

Konyaro

ps. ci-joint le fichier comm avec un maillage tout simple.

#16 Re: Salome-Meca usage » [SOLVED] Sequential calculation - IMPORT RESULTS from previous stage » 2020-05-10 07:53:18

Hello,
you can easily chain 2 analysis by defining ETAT_INIT() in the second analysis.

If you want to carry the first analysis and then continue with the second one separately you must use the command POURSUITE(), cf. documentation and forum. In Asterstudy you can simply add a stage and it will handle the POURSUITE for you.

Below an example of a 2 stages study. The trick in this study is the option DIDI in order to keep the displacements of the first study:

Poursuite

Konyaro

#19 Re: Salome-Meca usage » Rotational beam displacement question » 2020-04-22 05:01:56

Hello,
LIAISON_SOLIDE calculates displacements at the beginning of the simulation, which means the first direction of your rotation for each node will give the direction for the whole simulation. That's why you get a strange shape.

In recent versions of CA, LIAION_SOLIDE can be used with TYPE_CHARGE='SUIV' which actualizes the direction of the displacement, cf. https://code-aster.org/forum2/viewtopic … 539#p50539
Unfortunately it does not work in your case because it cannot link rotationnal DOF as your 3D elements don't have them cf. https://code-aster.org/forum2/viewtopic.php?id=23018
It's a pity it is not implemented I agree.

The remaining options are:
1) Use POU_D_T_GD, cf. https://code-aster.org/forum2/viewtopic.php?id=21253, which work well for small rotations. Some new beam elements should overcome these instabilities in the future, cf. https://code-aster.org/forum2/viewtopic … 357#p57357
2) Impose the position of the nodes with AFFE_CHAR_MECA_F, cf. https://code-aster.org/forum2/viewtopic … 420#p55420

Konyaro

#20 Re: Code_Aster usage » Friction force depending on the timestep » 2020-04-20 07:16:53

@mib : thank you for your advices. I made a few tests, normal force is always ok, only the friction force gets reduced, even for small deformations.

With ALGO_FROT='STANDARD' and ALGO_CONT='PENALISATION', the friction force is constant for any timesteps. I will try it on complex models to see if convergence is ok.

With ADAPTATION='ADAPT_COEF' convergence is hard to reach, so difficult to use with complex models I guess.

Nevertheless I remain surprised of the dependence of friction to timestep with ALGO_FROT='PENALISATION'.

Konyaro

#21 Re: Code_Aster usage » Friction force depending on the timestep » 2020-04-18 06:00:05

Hello,
Thank you for looking at my message.

It has the default value:

ADAPTATION='CYCLAGE'

Attached comm, med and mess.

Konyaro

#22 Re: Code_Aster usage » Friction force depending on the timestep » 2020-04-16 17:21:06

Hello Sameer,
Thank you for thinking about my question. I don’t think it is the right explanation for the following reasons:

- This phenomena exists for both dynamic and static analysis, for which time has no real meaning.

- If the COEF_PENA_FROT is high enough, the sliding force is constant for different timesteps. Unfortunately it is often not possible to set a high coefficient as convergence fails.

- Coulomb friction is used, which means the tangential force should equal the normal force multiplied by the friction coefficient when sliding. Power is not supposed to be constant.

Konyaro

#23 Code_Aster usage » Friction force depending on the timestep » 2020-04-15 19:32:00

konyaro
Replies: 42

Hello,
if the COEF_PENA_FROT coefficient is close to the convergence limit, the friction force depends on the timestep (CONTINUE, PENALISATION). Dividing the timestep by a factor 2 leads to the same results than dividing the COEF_PENA_FROT by a factor 2.

Is that a normal behaviour? It is quite dangerous because if the timestep is reduced automatically the friction force becomes wrong.

Below is depicted the friction force of a part sliding in the x direction on a fixed part. The timestep is divided twice and the sliding force depicted on the right gets also reduced twice.
COEF_PENA_FROT

Konyaro

#24 Re: Code_Aster usage » [solved]applying time and space varying function as boundary condition » 2020-04-15 13:25:02

If the formula is as simple as the one above you do not need Python:

P_func_Z = FORMULE(NOM_PARA=('INST','Z',),
                   VALE='INST * Z * 0.1');

loadWatF = AFFE_CHAR_MECA_F(MODELE=model,
                            PRES_REP=_F(GROUP_MA=('Group_loadWater260', ),
                                        PRES=P_func_Z))

Konyaro

#25 Re: Code_Aster usage » [solved]applying time and space varying function as boundary condition » 2020-04-15 06:13:22

Hello,
I think you can use a formule, something like:

def Fnirmal(INST,Z):
    x = INST * Z
    return x

P_func_Z = FORMULE(NOM_PARA=('INST','Z',),
                   VALE='Fnirmal(INST,Z)', Fnirmal = Fnirmal);

loadWatF = AFFE_CHAR_MECA_F(MODELE=model,
                            PRES_REP=_F(GROUP_MA=('Group_loadWater260', ),
                                        PRES=P_func_Z))

Konyaro