site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Hello,
Absolutely!
There's a subtle difference between STAT_NON_LINE and DYNA_NON_LINE.
Static prediction is made by a direct calculation based on the stresses of the previous time step, without integrating the behavior law (option in code_aster: FORC_NODA).
Dynamic prediction is made by integrating the behavior law (option in code_aster: RAPH_MECA).
In general, there is no difference. But in your case, yes!
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.
Hello,
Reference about what ? Problem of non-convexity sur contact surface ? Non-uniqueness solution for Coulomb Friction ?
Ah oui, tu as raison JP, j'ai aussi l'écho dans le output !
J'aurais pas du écouter mon voisin de bureau !
Hello,
Nice !
A good trick.
Thank you
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,
It's the same load.
We've made PRES_REP do the same thing as FORCE_COQUE/PRES for plates.
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
Bonjour,
Ce genre de remarques déplacées ne va pas aider.
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,
ode_aster is even more developed and active than ever.
On the other hand, we don't have any time to devote to animating the free community, including the website. This was already the case 15 years ago, and the time was taken from people's personal time (evenings and weekends).
Now, it's mainly devoted to EDF industrial issues.
I'd also like to make two comments:
- 10 or 15 years ago, one or two questions a week was manageable. Now it's several dozen, and the questions are particularly difficult.
- code distribution and tools keep pace with modern developments: containers, use of Git. There will also be major changes in documentation.
Finally, I notice that the community can't organize itself. It's open-source code, and apart from a few notable exceptions (like our Italian friends), it's mostly a collection of isolated people who come in once to ask a couple of questions and then disappear. Nevertheless, as many people answer the questions with accuracy and enthusiasm, I think it's not very nice not to notice.
After many years of hard work by our historical fathers, users are getting organized on the industrial side, with co-development agreements, particularly in the nuclear sector, or via highly professional solutions such as SimScale. I invite you to follow the news we regularly post on LinkedIn (often at weekends too...).
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.
This document is confidential and for EDF internal use only.
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
#
#--------------------------------------------------------------------------------
Hmmm ....
Your GROUP_MA='demi-cyl' is not correct.
In LIRE_MAILLAGE:
demicyl 2264 (without - )
Special characters as "-" or space are not a good idea
Hello !
Very nice ! Good job !
Many Mac users will be very happy!
Hello,
Answer is in the command file:
from code_aster.MacroCommands.Contrib.diffusion_H2 import (CHAMP_DETOILE,
CHAR_GRAD_IMPO,
CHAR_GRAD_INI,
CHAR_SOURCE)
in sources:
dev/codeaster/src/code_aster/MacroCommands/Contrib
https://gitlab.com/codeaster/src/-/tree … ds/Contrib
THe file is diffusion_H2.py
Hello,
Have a look on MODI_REPERE command
Hello,
Please avoid off-topic discussions.
There is only simulation, mechanics and code_aster on this site.
Thank you all!
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
See wdnp101 testcase for instance
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,
I don't know these commands. They were developed by someone else in the community and I have no information on the subject.
Sorry
Hello,
Strange request !
Do you use code_aster in another field than science or engineering ?
Hello,
CALC_CHAMP with this syntax, LIAISON_SOLID_SPH and IMPR_FONC_MULT are not part of code_aster standard commands.