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

You are not logged in.

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


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

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


In material properties

#5 Re: Code_Aster development » Is CA still being developed? » 2022-08-31 15:12:18

mecour wrote:


jeanpierreaubry wrote:

i do not understand this link sends me to a code_aster forum thread
which does not give any hint to compile a stand alone version of newer code_aster

you are right, all informations are about working and compilation inside container. I don't understand why developers force all to use container or salome-meca. It's a little bit ansys-workbench way.

Because I am not fan of containers nor salome-meca I was able compile the 15.5 version downloaded from sourceforge with version 14.6 settings (setup.py) only with change of src folder of aster and using newer mumps, ale other dependencies works. You just have to change the version of files in __pkginfo__.py

for me it was the solution for now, but maybe in future I will have to use salome-meca in container :-)


It is the only way to build code_aster now. We cannot support the old method ("from scratch") because we have several platforms on which to deploy code_aster/salome_meca and it is far too complex to manage with all the prerequisites required.

The real problem for me is the size of the final file (nearly 8GB in some versions).

#6 Re: Code_Aster usage » Orientation of faces in FLUI_STRU » 2022-07-31 21:37:59


VERI_NORM_IFS in AFFE_MODELE check normals are consistent for FSI analysis

#7 Re: Code_Aster usage » inconsistant mesh SOLVED » 2022-07-11 21:39:49

Hello,**You don't use the same mesh between AFFE_MODELE and AFFE_MATERIAU.

#8 Re: Code_Aster development » how to work with only nodes ?? » 2022-06-05 21:24:32


code_aster is a finite element code. It's non-sense to have only nodes, you need elements, you need a mesh.

#9 Re: Code_Aster usage » value of stress at nodes » 2022-03-17 23:32:58

CALC_CHAM_ELEM / COOR_ELGA => a field with coordinates of "Gauss points"
Just print it with IMPR_RESU

#10 Re: Code_Aster usage » [SOLVED] FORTRAN routines CA development material laws!? » 2022-03-09 21:43:18


Find the lcXXXX subroutine in behaviour's catalogs
=> dev/codeaster/src/code_aster/Behaviours/niceBehaviourForPasta.py
      num_lc = 98
     =>  lc0098.F90

#11 Re: Code_Aster usage » Validation de résultats Code Aster pour utilisation profesionnelle. » 2022-03-04 22:08:22


A ma connaissance, ces "certifications" n'existent pas en France pour les codes de calcul.

EDF a des processus de qualification liés aux exigences légales (décret), et contrôlées par l'autorité de sûreté nucléaire

https://www.asn.fr/l-asn-informe/actual … -nucleaire

#12 Re: Code_Aster usage » Validation de résultats Code Aster pour utilisation profesionnelle. » 2022-03-04 00:09:38


En gros, vous avez deux niveaux d'exigence dans un code de calcul:
- la vérification
- la validation
L'ensemble (le V&V) représente la qualification du code de calcul. La vérification est en général de la responsabilité de l'éditeur du logiciel, il est assuré par une série de tests vérifiant que les équations programmées dans le code sont bien correctes. Un éditeur commercial (tout comme aster) fournit une série de tests de vérifications avec le logiciel ainsi que le corpus documentaire permettant à un utilisateur de connaître les équations et hypothèses sous-jacentes.
Le processus de validation est spécifique à l'utilisateur. Il assure que le code de calcul réponde bien aux problèmes à simuler. Il est spécifique à chaque entreprise et industrie. Cette partie de la qualification pour code_aster est interne EDF et tout le processus est confidentiel (car il contient des données métiers).

Le code est soumis à des exigences spécifiques au nucléaire. Il est dit qualifié pour les études de sureté. Les exigences sont édictées en premier lieu par l'ASN, puis déclinés dans des processus internes. C'est extrêmement sévère, vous imaginez bien !

Il existe un manuel d'assurance qualité pour répondre à ces exigences. Ce manuel et les procédures qui y sont liées sont réservés à l'usage interne d'EDF.
Par ailleurs, l'ingénierie d'EDF(qui prononce la qualification du code pour ses usages) a d'autres processus qui la rende responsable des résultats obtenus par le code de calcul.
En particulier, elle s'occupe du processus de validation, du suivi des études et des prestations, ainsi que la traçabilité des résultats.

Ce que vous demandez, vous l'avez donc déjà: c'est la documentation (complète) et la base de cas-tests. Ni plus, ni moins qu'un autre logiciel (commercial ou pas).

Si vous voulez qualifier le code pour vos usages, c'est à vous de faire votre dossier de validation.
Comme vous devriez le faire (normalement) pour n'importe quel code de calcul (oui, on  l'habitude que les exigences des utilisateurs soient inversement proportionnelles au cout de la licence).

Je vous recommande (comme je le fais toujours) de ne jamais dire que code_aster est gratuit. Ce n'est pas vrai. le logiciel est open source et sa licence est gratuite, c'est vrai mais ça ne veut pas dire qu'il ne coute rien à utiliser.
Des industriels autres qu'EDF utilisent code_aster pour leur usage. Dans des tas d'industries (vous en trouverez sur ce forum). Vous pouvez leur demander comment ils ont fait. Ceux qu'on connait le mieux sont pragmatiques: ils ont pris le temps de faire leur dossier en faisant des calculs pour voir.
Et ceux qui réussissent le mieux sont ceux qui ont compris très tôt que ça allait leur couter du temps et de l'argent.

#13 Re: Code_Aster usage » Recherche d'un mailleur autre que MeshGems, Hypermesh/Hyperworks » 2022-03-02 21:48:24


Excellent mailleur open source qui exporte au format MED directement

#14 Re: Code_Aster development » waf configure failed » 2022-03-02 21:45:23


Oh yes !  Sorry !

You are not the first to come across this problem
We just changed the version of MUmps and this version is not yet distributed in OpenSource.
I think there is a way to force aster to use the old version, which is, I'm pretty sure, still compatible with the latest versions of aster

#15 Re: Code_Aster usage » MFront / different modelisations (HM, HHM) - a rather simple question! » 2022-03-02 21:42:05


You can use MFront for the mechanical part of  behaviour in THM modelling

#16 Re: Code_Aster usage » Issue with pre-stressed orthotropic structure and STAT_NON_LINE » 2022-03-02 21:40:57


Yes, this is a known limitation, related to the initial state. The only possible workaround I see for now is to use MFront

#17 Re: Code_Aster development » [solved] Correct folder for development in SRC » 2022-02-24 23:39:49


La doc n'est effectivement pas à jour.

Catalogue des comportements:

Fortran de la loi de comportement, quelque part dans bibfor:

=> mais y a rien de sûr, il suffit de chercher wink

#18 Re: Introduce yourself / Présentez vous » Hello again, banned without explanation » 2022-02-13 21:00:53

Probably it's a robot. I don't see a record of you being banned, so it wasn't done by one of the moderators

#19 Re: Code_Aster usage » Sugestion to improve documentation translation (with deepl). » 2022-02-13 10:06:17


1/ Original docuemnts are in LibreOffice format (odt). The translation should take into account the exclusion of keywords, unfortunately this feature never worked well.
We are using a commercial product that we have paid for, but the technical support is not up to par.

2/ The documentation of aster includes nearly 25000 pages, updated every day, for two simultaneous versions.
In addition, there is a QA process to validate modifications (reviews of documents). I remind you that this software is used in the nuclear industry, with its constraints and requirements

The very frequently asked question is also: why is the documentation in French?
This is for two reasons:
1/ The qualification requirements for the nuclear industry, the users of the code are French, there should be no risk of misunderstanding because of the documentation.
2/ The developers of code_aster do not all speak English, in any case, not at a sufficient level for the documentation to be of quality.

It's been 20 years since we wanted to involve the community for translation. Many attempts have been made and failed.
1/ The QA process is too cumbersome to rely solely on people of goodwill
2/ The volume of documentation is considerable
3/ The update computer system for documentation management is not intended for
4/ The odt format of the documentation does not lend itself to this (knowing that we had the worst difficulties in the world to switch from the historical Word format to LibreOffice)

The documentation is certainly both the weakness and the strength of the software.
Weakness because it requires considerable human, financial and material resources that obviously nobody wants to pay.
Strength because it combines 30 years of experience and knowledge of modeling.

Consider that we have not even succeeded in obtaining theoretical documentation in LATEX, which is very expensive for researchers who have to duplicate their work on the documentation

We still hope to be able to make a major leap in the documentation concerning at least the documentations of the tests and the commands.

The idea would be to change the format to something that would be manageable with the source code (rst, Sphinx), which would greatly facilitate both the update process and the translation by the community.
In addition, a large part of the information contained in these documents could be generated automatically from the source, which would reduce the sources of errosr.

Unfortunately, for the moment, this idea is not accessible, the developers wanting to do it would like to be able to sleep sometimes at night wink
We have serious hopes of change since the code_aster industrial community has grown.

#20 Re: Code_Aster usage » GIBI et Aster » 2022-02-12 19:47:20


Aster ne lit que des maillages, c'est un solveur.
Donc mgib uniquement
Et encore, ce format n'étant pas maintenu, je suis pas certain qu'on puisse lire des choses récentes. Le format et le mailleur de référence, c'est MED + salome

#21 Re: Salome-Meca usage » Magnitude of SIEF_ELGA » 2022-02-03 21:22:02

Hello for Paraview, magnitude is always


For displacement (on DEPL field):

But if you use non-isparametric element (as beams, plates, ...)

Careful when using contact (on DEPL field):

sqrt(dx^2+dy^2+dz^2+lags_c^2) with lags_c the lagrngian multipler for contact pressure
=> non-sense !

For stresses:

Absolutely useless  for mechanic !
Prefer von Mises or Tresca norm by compute SIEQ_ELGA in CALC_CHAMP.

#23 Re: Code_Aster usage » Contact with SIMO_MIEHE » 2022-01-26 22:04:05


With contact, PREDICTION='ELASTIQUE" is a good idea

#24 Re: Code_Aster usage » Error in STAT_NON_LINE » 2022-01-13 22:26:09


DST elements are not allowed in non-linear analysis.

#25 Re: Code_Aster usage » [SOLVED] - Echange and Maillage » 2022-01-08 10:44:43


Back to the finite element theory !

See  R3.06.02.

ECHANGE is solved by weak approach (integral), you need finite element on skin to make numerical integration

Dirichlet condition (temperature) DDL_TEMP is imposed by strong method, at nodes, without integral, you don't need skin elements