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

You are not logged in.

#2 Re: Salome-Meca usage » select body/surface in paravis » 2022-04-04 06:53:50

You must apply the "Extract Group" on the mesh (MED), not on the rmed result, and then link the extracted group to your result with the "Resample with dataset".

#3 Re: Salome-Meca usage » select body/surface in paravis » 2022-04-03 20:50:21

Ok, I was not able to to extract a group of surface-elements in your result file

This is explained in the Salome post I gave you above. Again, a workaround is to use the "Resample with dataset" filter.

#4 Re: Salome-Meca usage » select body/surface in paravis » 2022-03-30 20:35:19

Hello,
you can use the filter "Resample with dataset", refer to :
old.salome-platform.org/forum/forum_10/298627693#336367220

Konyaro

#5 Re: Salome-Meca usage » Solver pas présents (Code_Aster et Code_Saturne) » 2022-03-15 22:03:43

Bonjour,
vous avez installé Salome, pas Salome-meca. Un portage de Salome-meca 2019 vers Windows existe sur le site code-aster-windows.

Konyaro

#6 Re: Code_Aster usage » Contact with SIMO_MIEHE » 2022-01-27 10:43:17

Hello,
I often come across that problem. Contact analysis + GDEF_LOG or SIMO_MIEHE often leads to that error even if the parts shouldn’t meet large deformation. I saw the new option CONT_STAT_ELAS recently but couldn’t try yet as I’m still working with an old version. What I can nevertheless advise you:
- Check the quality of your mesh and try to improve it if needed, for instance by increasing the number of optimization steps in Salome.
- Add some discrete elements to all nodes of your spring in order to increase the stiffness of your model. That changes the results of course but sometimes a compromise can be found in order to reach convergence with satisfying results.

Good luck,
Konyaro

#7 Re: Code_Aster usage » [SOLVED] Boundary condition for contact probleme » 2022-01-21 17:23:17

Hello,
as written many times on this forum, I advise you to use a more robust contact formulation, for instance:

contact = DEFI_CONTACT(FORMULATION='CONTINUE',
                       FROTTEMENT='COULOMB',
                       MODELE=model,
                       LISSAGE='OUI',
                       REAC_GEOM='CONTROLE',
                       NB_ITER_GEOM=2,
                       ALGO_RESO_GEOM='POINT_FIXE',
                       ALGO_RESO_CONT='NEWTON',
                       ALGO_RESO_FROT='NEWTON',
                       ZONE=(_F(ALGO_CONT='PENALISATION',
                                ALGO_FROT='PENALISATION',
                                COEF_PENA_CONT=200000.0,
                                COEF_PENA_FROT=500.0,
                                COULOMB=0.5,
                                GROUP_MA_ESCL=('C_Top_rs', ),
                                GROUP_MA_MAIT=('C_Top_pr', ),
                                SANS_GROUP_MA=('E_common_p13', )), ...

regards,

Konyaro

#8 Re: Code_Aster usage » [SOLVED] DEFORMATION='GROT_GDEP’ and FORC_NODA moment equilibrium » 2021-12-10 09:39:48

Hello Micke,
I asked a similar question in https://code-aster.org/forum2/viewtopic.php?id=20771. I finally solved my problem by updating the mesh with the displacements before calculating the moment :

chDep = CREA_CHAMP(OPERATION = 'EXTR',
                   NOM_CHAM = 'DEPL',
                   TYPE_CHAM = 'NOEU_DEPL_R',
                   RESULTAT = resu1,
                   NUME_ORDRE = 10)  

mesh = MODI_MAILLAGE(reuse = mesh,
                     MAILLAGE = mesh,
                     DEFORME = _F(OPTION = 'TRAN',
                                  DEPL = chDep)) 
                                  
torque = POST_RELEVE_T(ACTION = _F(OPERATION = 'EXTRACTION',
                                   MOMENT=('DRX', 'DRZ'),
                                   ...

Konyaro

#9 Re: Code_Aster usage » Contact CONTINUE with SANS_GROUP_NO between slave surfaces » 2021-06-11 05:51:34

Hello Micke,
I asked the same question a few years ago but I guess it hasn't been improved yet:
https://code-aster.org/forum2/viewtopic … 704#p50704

Konyaro

#10 Re: Code_Aster usage » Run code_aster file with Matlab » 2021-04-23 05:56:50

Hello,
if you search for "run aster with python" on the forum you will get many results you can convert to Matlab. I use the following python script:

if os.name == 'nt':
    print('Lancement du calcul sous Windows')
    command = '{!s} {!s}'.format(os.path.join(repAsRun, 'as_run.bat'), export_file)
else:
    print('Lancement du calcul sous Linux')
    command = '{!s} shell -- as_run "{!s}"'.format(os.path.join(repAsRun, 'salome'), export_file)
process = subprocess.Popen(command, shell=True)
process.wait()

- repAsRun : path to your CA installation
- export_file : your export file

Konyaro

#11 Re: Code_Aster usage » Get the new coordinates of a deformed mesh » 2021-04-23 05:49:06

Hello,
your first solution should work, cf. attached file. Is it possible to share your comm file and mesh?

Konyaro

#12 Re: Code_Aster usage » [SOLVED] EXTR_TABLE does not work » 2021-03-22 09:22:13

Hello,
your object TBL is a tuple. If you do TBL[0].EXTR_TABLE(), it works. Nevertheless i don't know why it is a tuple...

Konyaro

#13 Re: Code_Aster usage » [SOLVED] Automatically generate filenames and units for .export file » 2021-03-04 17:03:26

Hello,
I often use the following without problems:

DEFI_FICHIER(ACTION='ASSOCIER',
             FICHIER=r'/usr/temp/Mesh.med',
             UNITE=3)
             
MAIL = LIRE_MAILLAGE(FORMAT='MED',
                     UNITE=3)

Don't forget the path of the file.

Konyaro

#14 Re: Code_Aster usage » Applying nodal displacements node by node » 2021-01-29 17:12:37

Hello,
you can do it easily with AFFE_CHAR_MECA_F, for instance :

def FdispX(INST, X, Y):
    R = sqrt(X**2 + Y**2)
    x = X / R * 0.05 * INST
    return x

deplX=FORMULE(NOM_PARA=('INST','X','Y',),
              VALE='FdispX(INST,X,Y)', FdispX=FdispX);

trans1=AFFE_CHAR_MECA_F(MODELE=model,
                        DDL_IMPO=_F(GROUP_NO='mondaiNai',
                                    DX=deplX,),);

Konyaro

#15 Code_Aster usage » LIAISON_GROUP: Il y a un conflit dans les vis-à-vis des noeuds » 2021-01-29 08:21:04

konyaro
Replies: 0

Hello,
I try to impose a cyclic condition on a compatible mesh with LIAISON_GROUP specifying ANGL_NAUT. I tried many different settings but always get the same error: "Il y a un conflit dans les vis-à-vis des noeuds [...]"

There is a similar post without solution:
https://code-aster.org/forum2/viewtopic.php?id=20628

Any hint welcome,

Konyaro

attached: MED, comm and mess files of a simple example.

#16 Re: Code_Aster usage » [Solved] Differences in convergence with different meshes » 2020-11-29 09:56:51

Hello,

Jesus wrote:

I don't know what do you mean with the file I use to mesh.

I meant a python dump file of your study (file --> Dump study).

I corrected the mesh and changed the contact parameters in order to make the simulation converge pretty fast.

Concerning the mesh parameters, you should rather ask your question on the Salome forum.

Attached mesh and comm file.

Konyaro

#17 Re: Code_Aster usage » [Solved] Differences in convergence with different meshes » 2020-11-23 20:40:28

There is something wrong with your mesh. There seems to be a common node to both parts. Can you share the file you used to mesh ?

#18 Re: Code_Aster usage » Advice needed on <EXCEPTION> <DVP_1> (DYNA_NON_LINE) » 2020-11-22 08:04:21

Hello,
it is possible to simulate the beginning of the crash of your ball on the plate with Code_Aster but once the distortion of elements gets too high the simulation will stop. You should investigate other ways:

1) Use of linear tetrahedrons can help but it won't be enough anyway.
2) Adaptive meshing would be an option but doesn't exist in Code_Aster. Homard can refine a mesh but not remesh a deformed mesh. Different commercial software handle it.
3) An explicit solver is a good option but I don't know any good opensource ones.
4) SPH could be an option with good opensource codes.

Konyaro

#19 Re: Code_Aster usage » [Solved] Differences in convergence with different meshes » 2020-11-21 14:31:52

Hello,
there are a few strange things in your model. I changed the followings:
- blocked only the Y direction as the model is axis-symmetric
- added weak springs as the upper part Y direction is not constrained (the stiffness may be too high)
- added a penalty coef. (you should adjust it) for the contact
- changed the contact zone for a larger one
- activated the automatic time-stepping
- changed the ALGO_RESO_CONT to POINT_FIXE in order to facilitate the convergence.

Attached the comm file.

Konyaro

#20 Re: Salome-Meca usage » Salome filling rate error » 2020-11-21 07:34:08

Hello,
your example with hex elements works fine. The message you mentioned is not an error, it is just an information about the matrix.

Attached the message file.

Konyaro

#21 Re: Code_Aster usage » [SOLVED] Resultant of FORC_NODA nodal foces on a (intenal) Group » 2020-11-17 06:57:19

Hello,
glad to hear that the resultant forces on free nodes equal zero otherwise the system would not be at equilibrium.

Konyaro

#22 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

#24 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

#25 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