Hello,

Yes, since V15.3, there is no longer a limit on the size of variable names in code_aster.
Documents are not up to date.

Ah oui, tu as raison JP, j'ai aussi l'écho dans le output !

J'aurais pas du écouter mon voisin de bureau !

Bonjour,

Depuis la version 15.3, aster est un module Python, le superviseur n'existe plus.
De fait, quand on exécute un script Python, vous n'avez pas l'écho de ce que vous avez écrit.
Il n'y a donc plus l'écho "du fichier .comm" car ça n'a plus de sens

Hello

Rubber and elastomer seals are extremely rare in the nuclear industry.

They are not very common materials, except for damping devices (e.g. earthquake and equipment vibration).

Most often, they are rigid joints, sometimes represented by a porous material.

If you need this kind os behaviour: ELAS_HYPER or MFront

Hello,

Don't worry.
These are legitimate and very frequent questions.

We have to deploy our software on many different types of media. The best tool at the moment is containers. A container contains salome_meca, but there's nothing to stop you using only code_aster, especially in the case of problems such as graphics cards.
Internally, code is qualified on platforms such as Debian10. Soon Debian11.
You can always compile code_aster externally. The only difference is that we no longer make "aster-full" packages, which had become too time-consuming. There are many prerequisites for code-aster. The salome-meca container contains them all, with the guarantee that they'll work whatever happens.
In addition, the sources are updated every week (in fact, every day) on the Gitlab repository, so nothing has changed in that respect.

About the support. The answer is: no.
EDF is an electricity producer, not a software vendor.
Some companies have tried to set up this kind of service, but the problem is that the French market is too small and it's not profitable for them.

For a long time now, we've known that the only solution is for the open-source community to organize itself so that this kind of service can emerge.
It's possible, but it's difficult. Don't forget that a mechanical computation code is an extremely complex object on a restricted market. Look at the size and power of the software editors in this market (ANSYS, Dassault Systèmes, etC.). This is no coincidence...

Hello,

Mazars' model doesn't fit EDF's needs. It's not robust enough.
We prefer other models.
We haven't done away with it yet, but we probably will soon.

Hello,

Solution (in you mail box

Using EVOL_CHAR in DYNA_VIBRA:

EVOL_CH=AFFE_CHAR_MECA(MODELE=MODEL,
                                                      EVOL_CHAR=resuChar,)

dynaResu=DYNA_VIBRA(BASE_CALCUL='PHYS',
                  TYPE_CALCUL='TRAN',
                  ...
                  EXCIT=(_F(CHARGE=EVOL_CH,),
                         ),
                  )

Problem: create resuChar !

The most versatil way:

resuChar=CREA_RESU(OPERATION='AFFE',
               TYPE_RESU='EVOL_CHAR',
               NOM_CHAM='PRES',
               AFFE=(
                     _F(CHAM_GD=presOne, INST=0.0, ),
                     _F(CHAM_GD=presTwo, INST=1.0, ),
                     _F(CHAM_GD=presThree, INST=2.0, ),
                    ) )

You have to create fields presOne, presTwo, etc...
Wz can use LIRE_TABLE + CREA_CHAMP

# Rank of table in file
instOne = 1
tablePresOne=LIRE_TABLE(UNITE=39,
                                                FORMAT='ASTER',
                                                NUME_TABLE=instOne,
                                                SEPARATEUR=' ');

presOne = CREA_CHAMP(OPERATION='EXTR',             
                                              TYPE_CHAM='NOEU_PRES_R',
                                              TABLE=tablePresOne,
                                              MAILLAGE=MA)

# Rank of table in file
instTwo = 2
tablePresTwo=LIRE_TABLE(UNITE=39,
                                                FORMAT='ASTER',
                                                NUME_TABLE=instTwo,
                                                SEPARATEUR=' ');

presTwo = CREA_CHAMP(OPERATION='EXTR',             
                                              TYPE_CHAM='NOEU_PRES_R',
                                              TABLE=tablePresTwo,
                                              MAILLAGE=MA)

Table file form:
#
#--------------------------------------------------------------------------------
#
#DEBUT_TABLE
#TITRE PRES - INST 1.0
NOEUD    PRES
K8       R       
A3       -100
A2       -200
A4       -300 
A1       -400
#FIN_TABLE
#
#--------------------------------------------------------------------------------
#
#DEBUT_TABLE
#TITRE PRES - INST 2.0
NOEUD    PRES
K8       R       
A3       -10
A2       -20
A4       -30 
A1       -40
#FIN_TABLE
#
#--------------------------------------------------------------------------------

Hello !

Very nice ! Good job !

Many Mac users will be very happy!

Hello,

Have a look on MODI_REPERE command

Hello,

You have some testcases about this strategy:
[V1.01.253] ZZZZ253 – Calcul non linéaire mécanique avec changement de maillage
[V6.03.158] SSNP158 - Adaptation de maillage en non-linéaire

Hello,

Yes, this is a known issue

False results were noticed on a study for the penalized formulation of friction (for non-zero coefficients of friction of course). Risk of false results for this friction formulation pending instruction.

There are currently works to have a more reliable formulation.
The other methods (augmented Lagrangian) give correct results but do not always converge.

Hello,

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