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

You are not logged in.

#1 Re: Code_Aster usage » If you can see this question, would you like to give me some suggestio » 2022-06-13 09:47:16


I can recommend to you Jean-Pierre Aubry's great book on getting started with code_aster.
You can get it from this source https:__//archives.framabook.org/beginning-with-code_aster/ (remove __)
It contains a working example for non-linear calculations with friction-contact and is overall a great way to get to know code_aster.

If you need further informations you should read up on the documentation, for example

[U2.04.04] Instructions for use of contact

and of course the documentation of the individual Aster-Operators.

Hope this helps,


#2 Re: Introduce yourself / Présentez vous » Best Python Courses » 2022-06-08 06:48:28

Hello Palak, a few years back I learned the basics of python using the following course on Youtube:

https:__//www.youtube.com/watch?v=rfscVS0vtbw (delete the __, because you can't post links here)

I found it to be a very well structured and comprehensive tutorial for beginners, and it covers most of the basics in about 4 1/2 hours. If you already know other programming languages, the pacing might be a little slow for you, but then again, it is only 4 1/2 hours.
For everything else, for example if you need solutions for specific problems (meaning code examples) I recommend stack overflow.


#3 Re: Code_Aster usage » strange reaction force at constraint » 2022-05-09 18:18:11

Ok, sadly there have been no answers, but I did check a few things the last few days and I made some progress, even though the false reaction-forces still remain.

I tested virtually everything. I tested if different orientations of the shell-elements, that carry the constrained nodes, could be the reason, but it had no effect.

I think I can pin it down on my use of LIAISON_MAIL (MASSIF_COQUE), which I use to connect 3D-Elements and shell-elements, in combination with the modelisation COQUE_3D. Interestingly, if I switch to MODELISATION = 'DKT' for the shells, the calculated reaction forces are as expected. Only when I use COQUE_3D, I get this discrepancy.
I think there is nothing wrong with the solution in general, only with the calculation of the reactions at the constraints, since the linear and quadratic results are very similar, and I double-checked with our commercial FE-software.

Has someone else experienced the described phenomenon, when using LIAISON_MAIL and COQUE_3D?

Further, I was not able to reproduce this effect. I tried so with a smaller, more basic model, which I could share in this forum, but the problem didn't occur there.


#4 Re: Code_Aster usage » Best method to apply force » 2022-05-06 09:55:13

I personally would always prefer distributed load-definitions like FORCE_FACE or FORCE_COQUE, etc. compared to FORCE_NODALE. FORCE_NODALE applies a constant force to every referenced node. So if your mesh is more refined in some areas, the load concentrates on these areas. The other load-definitions distribute the load onto the nodes by area.

In most cases this effect should be small, but I think it is good practice.


#5 Code_Aster usage » strange reaction force at constraint » 2022-05-04 07:53:41

jonas loenartz
Replies: 1

Hello everyone,

I obtained strange results, when I calculated the reaction-forces at the constraints, which I can't quite explain myself.
I have two gravitational loads in negative z-direction as defined in the following code samples:

eigengewicht_gestell = AFFE_CHAR_MECA(
   MODELE = model,
      GROUP_MA = ('s_doppel_20mm', 's_doppel_30mm','s_profile_10mm', 's_profile_20mm', 'v_aufhaengung'),
      GRAVITE = 9810.0,
      DIRECTION = (0.0, 0.0, -1.0),

eigengewicht_m_vert = AFFE_CHAR_MECA(
   MODELE = model,
      GROUP_MA = ('m_5200kg'),
      GRAVITE = 9810.0,
      DIRECTION = (0.0, 0.0, -1.0),

The second gravitational load "eigengewicht_m_vert" only affects a point-mass POI1, which is connected via LIAISON_SOLIDE to the rest of the model, while the first load "eigengewicht_gestell" affects the rest of the model. I used two seperate loads, because in further loadsteps I want to change the direction of only the second gravitational force.

Because the gravitation in x- and y-direction is 0.0, I would expect the reaction forces at the constraints to be near 0 in these directions as well, considering numerical imprecisions.

I calculated the reaction forces as usual, using

      RESULTAT = lin_stat,
      RESULTANTE=('DX', 'DY', 'DZ',),

and printed it to the resu file.
The mass of the model calculated using POST_ELEM is 6.165t (mm-t-s used here)
So I would expect the following reaction forces: DX = DY = 0, DZ = 60479.
This is what was printed in my .resu-file:

INTITULE         * RESU     * NOM_CHAM         *  NUME_ORDRE   *  INST         *  DX           *  DY           *  DZ          
Kräfte           * 0000001a * REAC_NODA        *             1 *     0.000E+00 *    -3.947E+02 *    -3.148E+02 *     6.005E+04

As can be seen, the reaction-forces are very much not 0. I cant quite explain this, because there should literally be no force at the constraints in any other direction than negative z.
Does the use of LIAISON_ ... introduce inaccuracys into the model perhaps?

Attached are two more verbose command-files, one used for the calculations, and one used for the postprocessing. I can't share the model due to confidentiality and it is way to big.

Thanks and greetings

#6 Re: Salome-Meca usage » select body/surface in paravis » 2022-03-31 08:50:29

jacob wrote:

hmm on volme it works, but not on the surfaces.
However I have to prepare everything before solving I guess?

Ok, I was not able to to extract a group of surface-elements in your result file. General it shoud be possible (as you can see in the attached screenshot, where I did it with one of my models.)

I'll have a look into your model later when I have time, in order to check if everything defined correctly in there


#7 Re: Salome-Meca usage » select body/surface in paravis » 2022-03-30 13:39:35

The filter has so far not failed me. But your property-browser looks kind of strange to me, as if you are not using the filter on the right object. It looks like your result file is "leaf_spring_contact_AS.rmed" but you use it on some other object in the pipeline browser. You have to select the object you want to apply the filter to in your pipeline browser, so that it has a blue background.

it would help, if you could share the .rmed file


#8 Re: Salome-Meca usage » select body/surface in paravis » 2022-03-30 07:35:58

Hello Jacob,

if you use Paravis for your post-processing you can also use the filter "extract groups", to isolate the values by mesh groups (GROUP_MA and GROUP_NO) you defined during the pre-processing. No need to choose cells in advance.


#9 Re: Code_Aster usage » HEXA20_27, PENTA15_18 and the conformity of the mesh » 2022-03-18 13:47:13


Have you found an answer to this issue? Because I am very interested in this topic, too. I use a pre-processor, that is not able to create bi-quadratic meshs and so far I only used CREA_MAILLAGE, to get bi-quadratic shell-elements. I have found it increasingly difficult to get contact-problems to converge with simple quadratic 3D-elements. It would be great, to be able to transform mixed meshes as well.

In principal it is possible to transform mixed quadratic meshes into bi-quadratic meshes using the mesh module in Salome-Meca. It would be great though, if this extra step were not neccessary.


#10 Re: Code_Aster usage » Bond shells together by nodes » 2022-03-08 12:36:19


LIAISON_SOLIDE uses by default


and it expects the nodes of the defined groups to have only the three translational degrees of freedom. The nodes of the shell-elements carry 6DOF
I suggest using


for GROUP_MA_MAIT you select the rectangular plate and for GROUP_MA_ESCL you define edge elements on the end of the pipe you want to connect to the rectangular plate, (or GROUP_NO_ESCL with the nodes on the edge of the pipe you want to connect)

For more details check out the documentation [U4.44.01]


#11 Re: Salome-Meca usage » Unpredictable behavior of SM2021 - MPI » 2022-03-07 20:30:29

mf wrote:

Does anyone else see this behavior and knows how to resolve? I know it would be easier to resolve if I attached .comm etc. In this case, I am not allowed to do that sorry.

Hello, I had the same issue today. I am using the container you provide on GitHub (so far no problems! thanks again for the work -- > https:__//github.com/emefff/Code-Aster-MPI-in-Singularity-of-SM2021). I normally use ASTK to run my cases, but I thought about switching (going with the time ...). First try, first issue I guess.
I too can't share a  .comm file due to confidentiality...

I try to paint a picture what happened though:

  • Stage from text-file,

  • Only the mesh-file defined as input

  • Output defined in second comm-file (stage) but the error came right after finishing the run of the first stage (STAT_NON_LINE)

Have you been able to narrow it down?

I attached a screenshot of the strange behaviour

#12 Code_Aster usage » issue (possible bug?) concerning POST_RELEVE_T » 2022-03-05 12:07:18

jonas loenartz
Replies: 0

Hello everyone,

I have a question concerning the operator POST_RELEVE_T.

In a case I'm working on right now I defined 3D-faces, in order to use them with AFFE_CHAR_MECA --> FACE_IMPO.

I want to use POST_RELEVE_T to calculate the reaction-force of this constraint by using

                                   INTITULE='Summe Reaktionskräfte',
                                   RESULTANTE=('DX', 'DY', 'DZ'),

* This is the more verbose output of the command in the mess-file

I used this exact formulation lots of times, but with GROUP_NO instead of GROUP_MA.
Now I get the error-message:

 ║ <EXCEPTION> <SUPERVIS_4>                                                                       ║
 ║                                                                                                ║
 ║ Erreur de syntaxe dans POST_RELEVE_T                                                           ║
 ║                                                                                                ║
 ║ At least one argument of ('GROUP_NO', 'NOEUD') must be defined                                 ║
 ║                                                                                                ║
 ║ Exception détaillée ci-dessous.                                                                ║

I find this a little strange, because the documentation [U4.81.21] states at page 5, that you can use GROUP_MA to specify a list of mesh-groups, and that it can't be used in combination with GROUP_NO. I never had any problems with POST_RELEVE_T before, but this is the first time I tried using it with GROUP_MA.

Thanks in advance,

#13 Re: Code_Aster usage » LIAISION_MAIL problem » 2022-03-04 09:31:39

jeanpierreaubry wrote:

the mesh that i have downloaded does not contain a 3D group named CERCHIONE
is that a problem with window$ created mesh? i do not know
could you share the mesh you are using

Sorry for my late answer. Yes, I used the same mesh and I saw that there is no CERCHIONE, I stopped the execution after LIAISON_SOLIDE, thats why I had no error.

@Giuseppe Faggiano

your boundary conditions, as M. Aubry mentioned, are indeed a mistery to me, too. Are you modeling only a section of the rim and the hub and try to impose a circular boundary condition on the symmetry-faces?


#14 Re: Code_Aster usage » LIAISION_MAIL problem » 2022-03-03 14:13:50

Ok, I see, you reduced the mesh size in order to post it in the forum. I misunderstood previously. I thought you meant your hardware-memory. Can you share the real mesh on some file-hoster and share a link perhaps?

LIAISON_SOLIDE is not necessarily the problem. You log-file says the matrix is not invertible, because the matrix is singular. This can happen, when your model is not fully constrained and you have rigid-body motion.

Do the GROUP_MA_ESCL and GROUP_MA_MAIT of your LIAISON_SOLIDE share any nodes perhaps?


#15 Re: Code_Aster usage » LIAISION_MAIL problem » 2022-03-03 11:49:24


could you post the *mess-file as well? I ran your command-file with version 15.4 and didn't get an error for  LIAISON_MAIL, only an alarm for a distant node.

I also got alarms for duplicate elements and

La maille M86 porte un élément fini de bord, mais elle ne borde aucun élément ayant une "rigidité".

There also are some very questionable elements in your model, so I doubt it would run, even if you fixed the LIAISON_SOLIDE,
and there is only a single 3D-mesh zone for the hub. You definetely have to check your mesh.


#16 Re: Code_Aster usage » Strange behaviour of residuals with MPI version SM2021 (MUMPS solver) » 2022-02-26 09:38:45

Thank you for the answer, yes, the settings were kept from another machine with more cores, when I transferred the case. I tested it on another machine, and the behavior is the same.

But I noticed I made a mistake in my model. Some nodes were simultaniously defined as slave-nodes in multiple LIAISON_ interfaces (even though the results were plausible, when the calculation ran to completion).

When I fixed that, the mpi-settings don't seem to have an effect anymore. But nonetheless it would be interesting to know, what caused this kind of behavior while solving.

I will keep the thread open for another week, before I mark this issue as solved. Maybe someone has an explanation.


#17 Re: Code_Aster usage » [SOLVED] Non zero strain after DDL_IMPO set to zero » 2022-02-25 17:47:11

By doing that I've strain in the order of 10^-16 and 10^-18 in the X and Y directions. Why is this value not zero ? Because of the precision of code_aster ?

Also if I may ask, can you explain me why doing what you told me solved my problem ?

Yes, it is 0, but due to the precision (not the precision of code_aster, but numerical precision of a computer in general) you have the very small residual value.

And for your second question, you blocked only the DOFs on the faces you specified in the direction you specified. So contraction was still possible, because the other nodes were able to move towards the constrained faces. By blocking the opposite faces as well, you locked the width of the cube.

I can really recommend to you working through Mr. Aubrys book. It helped me a lot, getting started with code_aster. But I had some experience with FEM before.

#18 Re: Code_Aster usage » [SOLVED] Non zero strain after DDL_IMPO set to zero » 2022-02-25 17:26:58

Ok, what I think you are trying to achieve, is achievable by blocking DX for the 'frontface' and DY  for the 'rightface' as well.

load = AFFE_CHAR_MECA(identifier='6:1',
                                   GROUP_MA=('topface', )),
                                   GROUP_MA=('rearface',  'frontface')),
                                   GROUP_MA=('bottomface', )),
                                   GROUP_MA=('leftface', 'rightface'))),


#19 Re: Code_Aster usage » [SOLVED] Non zero strain after DDL_IMPO set to zero » 2022-02-25 15:04:18

Based on what I can deduct from your command-file, the faces opposite can still move freely towards the constrained faces.


#20 Re: Code_Aster usage » [SOLVED] Non zero strain after DDL_IMPO set to zero » 2022-02-25 13:53:56


The elongation in z-direction leads to lateral contraction of the cube, and this should result in a strain-component in the x- and y-direction.

edit: strain-component

#21 Code_Aster usage » Strange behaviour of residuals with MPI version SM2021 (MUMPS solver) » 2022-02-25 13:37:15

jonas loenartz
Replies: 2

Hello everyone,

I encountered strange behaviour running an analysis today when using MUMPS solver with the mpi-version.

With the following mpi-settings, everything goes as planned, and the study runs towards completion without errors:

  • ncpus = 1; mpi_nbcpus = 2

  • ncpus = 2; mpi_nbcpus = 2

But when I change it to:
ncpus = 1; mpi_nbcpus = 4

I get the following error message:

 ║ <EXCEPTION> <FACTOR_57>                                                                        ║
 ║                                                                                                ║
 ║ Solver MUMPS:                                                                                  ║
 ║  The solution of the linear system is too vague:                                               ║
 ║  Computed error:  120.491                                                                      ║
 ║  Acceptable error:  1e-06 (RESI_RELA)                                                          ║
 ║                                                                                                ║
 ║  Advices:                                                                                      ║
 ║  One can increase the value of the key word SOLVER/RESI_RELA.                                  ║

The machine I use to run the study has 4 cores.
Is the residual supposed to change based on the mpi-settings (to this degree)?
Is there anything I have to specify in the command-file considering distribution of the model in order to not get this error?

Maybe someone else has encountered this before, but I couldn't find a thread in the forum, concerning this kind of issue.


PS: I attached the .comm and the .mess file, just in case

#22 Re: Salome-Meca usage » Workstation/PC builds for simulations with Salome-Meca/Code_Aster MPI » 2022-01-23 08:53:57


This built looks pretty good in my opinion, but mainly, if you plan to use it as a PC and occasionally as a workstation for simulations.
Here are some things I think you should consider.

These are mainly consumer PC parts you are listing. This gets especially relevant when it comes to CPU/GPU. The Ryzen 5950x as well as every other consumer model on the market right now only support dual-channel RAM. If you look at the threadripper models by AMD or the Xeon models by Intel, they support 4 or even 8 memory channels. FE-simulations are heavily memory bound, and you will encounter a bottleneck by using dual-channel memory.

I for example have the AMD Ryzen 3950X (16 core), 64Gb DDR4 Ram 3200 MHz (the rest is not that important for this at the moment).

At work I currently use a 5 year old machine with a 28 core Intel Xeon 2,5 GHz processor  and 256Gb of Ram (2666 MHz).
The machine works with 4 RAM channels.
(I don't have all specs in my head, like cache data, but this is more to show you the difference a setup, that is built for this kind of work, can do).

The 5 year old workstation is on average around 30% faster than my PC/workstation at home (same case-setups). In especially memory consuming cases, the gain in speed can even reach around 40-50%.

So my conclusion is, if money isn't an issue and you are planning to use the machine mainly as a workstation for FE-simulations, you should think about going with Threadripper or Xeon models.

If you want a highend PC you use mainly for other stuff like gaming, office-work, pre- and post-processing for FE, etc. and occasionally do hardware-consuming simulations, than the built is a good as it gets I think.
I have no experience with DDR5 memory, but the higher bandwidth could theoretically speed things up quite a bit.

best regards,

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


Sometimes you can encounter the problem of a singular matrix, when parts of your mesh are only "held in place" by the contact (even if it is only certain DOFs), because of rigid body motion.
I had a similar issue in the past and the way I solved this, was, by adding CONTACT_INIT = 'OUI' and SEUIL_INIT = 1.0.
You basically say, that the initial contact state is 'true" and to block lateral motion, you set an initial value for contact pressure in your prefered unit-system (1.0 in the code snippet) . This applies only for the initial steps of your calculation and won't be reflected in the results.

                                GROUP_MA_ESCL=('C_Top_rs', ),
                                GROUP_MA_MAIT=('C_Top_pr', ),
                                CONTACT_INIT = 'OUI',
			        SEUIL_INIT = 1.0,
                                SANS_GROUP_MA=('E_common_p13', )),

would be the way to go here. If your calculation still doesn't converge, you can try increasing SEUIL_INIT.

Good luck and I hope this will do the trick!

#24 Code_Aster usage » ASTK --> files relative path problem in SM_2021_mpi » 2022-01-17 08:34:40

jonas loenartz
Replies: 0

Hello everyone,

I encountered the following "problem" with ASTK (MPI-version of Salome Meca 2021, Singularity Container) :

The files in ASTK seem to always be defined by their absolute path.

Lets say I choose for base path


and define my .comm-file as relative to said directory:


When I now change the base path to


the path of my command-file changes to


So it basically has not changed the absolute path of the file, which makes the point of a base path obsolete.
In ASTK shipped with Salome Meca 2020 I was able to switch between base paths, and the relative filenames stayed the way they were. Is there something in the settings I have overlooked? Or it supposed to be this way? Has it something to do with container rights?

Thanks in advance,

#25 Re: Code_Aster development » MED documentation » 2021-12-16 11:55:33

Thank you for your answers. Following nicolas_ps suggestion I found the following information on several APIs to read/write MED-files.


Sadly I won't be able to utilize these because I can't access these APIs in Hyperworks TCL-interface. I will work with the .unv or .mail file format and convert them to .med using Code Aster.

But thank you JanBlokes for the information on meshio. I did not know about his tool and it seems to be very useful!