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

You are not logged in.

#1 Code_Aster development » Retrieve messages triggered by call utmess('I', ...) with Python » 2022-03-23 16:33:14

Replies: 0

Hi everyone,

Is there a way to retrieve the list of messages triggered by call utmess('I' ...) (i.e. with Info level) throughout the simulation's execution by means of Python??

A more specific example:

During the Newton loop, I get the following message:

<Erreur> Le nombre maximum d'itérations de Newton est atteint

which is a message triggered by the call of utmess('I', 'MECANONLINE10_3') during the Newton loop.

This is followed by a thrown DVP_2 exception.

I would like to retrieve, in this case, the message in 'MECANONLINE10_3'.

I have tried getting Info messages by means of:

from Utilitai.Utmess import MessageLog, list_unit
info_and_alarms = MessageLog.get_info_alarm()

but this only gives me the list of ALARMS and not the info messages.

Any help is appreciated!


#2 Code_Aster usage » Modify field contained in a resultat_sdaster using Python » 2022-02-21 13:01:04

Replies: 1

Hello everyone,

Given the fact that I have a result object from a non-linear static computation (i.e. an instance of an evol_noli) like the following:


How can I modify the values in the memory of e.g. the component LAGS_C of the field DEPL by means of python and the aster data structures contained in RES?

I try to avoid the procedure of creating a new field with CREA_CHAMP with exactly the same values as those coming from STAT_NON_LINE, but with just a couple of modifications to LAGS_C, to later create a new result with CREA_RESU.

Any idea on how to achieve this would be really appreciated.

Best regards,

#3 Re: Code_Aster usage » [SOLVED] adding nodes using MAIL_PY() » 2021-11-15 17:37:29

You're welcome!

Don't forget to prepend [SOLVED] to the name of the thread in the case that you found the solution helped to solve your doubts smile

#4 Code_Aster usage » HELP: usage of PENE_MAXI in DEFI_CONTACT when ALGO_CONT='PENALISATION' » 2021-11-11 16:46:03

Replies: 0

Hi everyone,

I have a question on how to use PENE_MAXI in a contact zone within DEFI_CONTACT when the Penalization contact algorithm and ADAPTATION='ADAPT_COEF' are selected.

According to the documentation (code-aster.org/V2/doc/v14/fr/man_u/u4/u4.44.11.pdf) the penalization coefficient (COEF_PENA_CONT) will be updated in every contact iteration in order to satisfy the maximum allowed penetration (defined by PENE_MAXI). It also says that if PENE_MAXI is not defined, Code_Aster will automatically set it as 1e-2 times the minimum edge of the underlying contact zone. However, no matter what value I assign to PENE_MAXI, it seems that the contact penetration is always going to values of ~1e-3 all the time (which makes me believe that it's always using the default value).

Here is the relevant extract of the .comm file:

                        FORMULATION    = 'CONTINUE',
                        ALGO_RESO_CONT = 'POINT_FIXE',
                        #ALGO_RESO_FROT = 'POINT_FIXE',
                        ALGO_RESO_GEOM = 'POINT_FIXE',
                        LISSAGE        = 'OUI',
                        #FROTTEMENT     = 'COULOMB',

                    ZONE =(
                             GROUP_MA_MAIT ='FIL_MAI1',
                             GROUP_MA_ESCL ='LOP_ESC1',
                             CONTACT_INIT  = 'INTERPENETRE',
                             GLISSIERE     = 'OUI',
                             #COULOMB       = 0.,
                             GROUP_MA_MAIT ='LOP_ESC2',
                             GROUP_MA_ESCL ='FIL_MAI2',
                            ALGO_CONT = 'PENALISATION',
                            #COEF_PENA_CONT = 1.E4,
                            ADAPTATION='ADAPT_COEF',        # <------------------- HERE
                            PENE_MAXI=300,                              # <------------------- and HERE

I also read somewhere in the source code that when ALGO_RESO_CONT = 'POINT_FIXE', the value of the penalization coefficient is updated, but the residuals are never checked. Therefore, the max penetration is never considered as a convergence criteria, why is that?

Does anyone have experience with this setting in the contact definition with CONTINUE formulation? I would really appreciate any insights into how to interpret the residuals given by this option, as well as clarifying why is the PENE_MAXI not respected.

I've been using the benchmark ssnv504k (code-aster.org/V2/doc/v14/fr/man_v/v6/v6.04.504.pdf) to test the effect of changing PENE_MAXI. To save you some time, attached are the needed files for the simulation.

Thank you in advance,


#5 Re: Code_Aster usage » Store last converged step » 2021-11-11 16:21:38

filjan wrote:

Add in .comm python clause try/except, like:

You are right, this might be an easier approach if you want to keep it on the same .comm file as per in this document: code-aster.org/V2/doc/v14/en/man_d/d5/d5.01.02.pdf (page 8, 5.5. Recovery of the exceptions in macro):

    __resu = STAT_NON_LINE (...)
except NonConvergenceError ace exc:
    resu = self.get_last_concept ()
    # I assume here you'll have to do your IMPR_RESU:


#6 Re: Code_Aster usage » [SOLVED] adding nodes using MAIL_PY() » 2021-11-11 15:43:27

Hi z-1616,

Here is a small script that add nodes to a mesh with MAIL_PY() :

# Creation of python mesh
mesh_py = MAIL_PY()
mesh_py.FromAster(MAILLAGE)  # read MED mesh and make it a python object

# Dictionary containing node's name as keys and node's coordinates as values
additional_nodes_dict = {
    "node_1": [x1, y1, z1],
    "node_2": [x2, y2, z2],
    "node_n": [xn, yn, zn]

 # Node Names are given in mesh_py.correspondance_noeuds
list_of_node_names= list(mesh_py.correspondance_noeuds)
# Initial number of nodes
init_no_nodes = mesh_py.dime_maillage[0]

# Node coordinates to add:
node_coordinates = NP.zeros((len(additional_nodes_dict), 3)) # initialize a numpy array with size N rows and 3 columns (N is the number of nodes to add)
node_names = [] # initialize empty list of node names

for ii, node in enumerate(additional_nodes_dict.keys()):
        # 1. add node coordinates to numpy array
        node_coordinates[ii] = NP.array([additional_nodes_dict[node]])
        # node_names =     ['X%' %node] ->>>> THIS IS ONE OF THE THINGS YOU WERE WONDERING ABOUT
        node_names.append('%s' % node) # The '%s' is simply a string interpolation (%) of whatever the variable 'node' is storing, i.e. the node's name
        # Add node group to mesh
        group_name = node
        add_node_number = init_no_nodes + ii  # e.g. NUM_OF_NODES_IN_YOUR_MESH + 1
        mesh_py.gno[group_name] = NP.array([add_node_number])  # add node to mesh
# Add nodes to MESH : coord, name
mesh_py.cn = NP.concatenate((mesh_py.cn, node_coordinates))  # add node coordinates to mesh
mesh_py.correspondance_noeuds = tuple(list_of_node_names + node_names) # add node names

# Finally, update node count
number_of_nodes_to_add = len(additional_nodes_dict)
mesh_py.dime_maillage = list(mesh_py.dime_maillage)
mesh_py.dime_maillage[0] = init_no_nodes + number_of_nodes_to_add
mesh_py.dime_maillage = tuple(mesh_py.dime_maillage)

This is how you would add nodes to your mesh by assuming you have a map (dictionary) between your node names and their coordinates.

Hope you find it useful.


#7 Re: Code_Aster usage » Store last converged step » 2021-11-11 14:54:37

Hi APereira,

How exactly are you running your simulation? Is everything in a single .comm file (i.e. the IMPR_RESU operator printing the results to the MED file is in the same file as your e.g. STAT_NON_LINE)? If this is the case, then I'd recommend that you split your .comm file into 2 of them: one for the DEBUT procedure (where the material assignment, boundary condition definition, mesh group creations, etc., are defined) and in a second file the POURSUITE (i.e. continuation) procedure, which will contain everything related to your post-processing steps.

Here is a small example for your first file:

# Input file start

# Definition of material(s)

# Define mesh file

# Creation of node groups and so ...

# Model definition of phenomena and element types

# First bc

# Second bc

# and more

# Nonlinear static analysis definition
     # And whatever other setting you might have or want

# End of your simulation step (WITHOUT POSTPROCESSING)

In a second file:

# Input file start


# Solution fields in file
        ... # Whatever field you'd like to post-process
# End of your post-processing step 

Now, I normally run my simulations with as_run by executing from the terminal:

as_run simulation.export

and subsequently:

as_run postproc.export

where simulation.export and postproc.export would look something like this, respectively:

P actions make_etude

P rep_trav <#IMPORTANT: here goes the PATH where the global directory will be written to. This directory will contain all partial/complete data generated by your simulation (independently whether it was successful or not, meaning that if you had already some written steps, they'll appear here)>

F comm PATH_TO_YOUR_SIMULATION_COMM/simulation.comm D  1
F mmed PATH_TO_YOUR_MED_MESH D/mesh.med  D 20
F erre PATH_TO_YOUR_ERROR_MESSAGES/errors.mess R  9


P actions make_etude

P rep_trav <#IMPORTANT: here goes the PATH where the global directory was written to. This directory will contain all partial/complete data generated by your simulation (independently whether it was successful or not, meaning that if you had already some written steps, they'll appear here) and will be used in this step as a starting point>

F comm PATH_TO_YOUR_POSTPROC_COMM/postproc.comm D  1
F rmed PATH_TO_YOUR_RESULT_MED_MESH D/result.rmed  R 80
F erre PATH_TO_YOUR_ERROR_MESSAGES/errors.mess R  9

If you instead use ASTK within Salome Meca, then all the info in the .export files is exactly the one that you will fill in there (but with a somehow "nicer" UI).

Now, if you use AsterStudy... then I cannot further help you smile

With this you should at least be able to access the last converged simulation step (ofc, as long as you printed it out in ARCHIVAGE or something alike)


#8 Re: Code_Aster usage » Overconstrained DOFs with FACE_IMPO for symmetry » 2021-04-16 11:42:06

Thanks for your reply Ect.

I have tried that before. Nevertheless, by doing what you propose, I am removing a group of nodes from the symmetry condition, which will result in wrong behavior. Take as an example the following:

Assume that instead of imposing only 0 displacement/rotation to the nodes of the top face (as depicted in the image I shared) I do the following:

mesh = DEFI_GROUP (reuse = mesh, MAILLAGE = mesh,
             CREA_GROUP_NO = (
                 _F (NOM='exclude', INTERSEC=('face1','face2')),

# Let's apply a displacement in the X direction on the top face

symm = AFFE_CHAR_MECA(...
                  _F(GROUP_MA='face1', DNOR=0.0, SANS_GROUP_NO=('exclude',)),

then, the nodes on the shared edge between disp and symm will have some displacements in the y-direction, violating the symmetry condition.


#9 Re: Code_Aster usage » Generation of 0D elements » 2021-04-11 18:45:23

Hi MrSnail,

In order to do it from the UI:
1. In the Salome-meca mesh module, click on Modification -> Add -> 0D Elements on Element Nodes
2. Select the node(s) you want to create 0D elements for, click the checkbox Add to group and name the 0D element group (e.g. mass 1)
3. Now you are able to use these 0D element groups in Aster study

Assuming you have node groups out of which you'd like to create 0D elements:
In the Code_Aster command file you have to write something like this:

    GROUP_NO=('support', ), 
    NOM_GROUP_MA=('mass_1', )

What this is doing is creating POI1 elements (i.e. 0D elements) out of a node group called "support" (defined in the mesh module), and naming this group "mass_1" (just an example).
(This in Aster study is under Mesh -> CREA_MAILLAGE)


#11 Code_Aster usage » Overconstrained DOFs with FACE_IMPO for symmetry » 2021-04-09 14:01:10

Replies: 4

Hello everyone,

I've been working on a simple model like the one in the attached image (bc_setup.png). The problem is simple:

1. I impose a symmetry boundary condition on the cylindrical face by means of:


2. Then, on the top face I impose a fixed constraint by means of:


3. Finally, I apply a face force on the bottom face:


After running my simple linear static simulation (MECA_STATIQUE) I run into the following problem:

   ! <EXCEPTION> <FACTOR_11>                                                                                                      !
   !                                                                                                                              !
   ! Problème : la matrice est singulière ou presque singulière :                                                                 !
   !   Lors de la factorisation de la matrice, on a rencontré un problème                                                         !
   !   (pivot nul ou presque nul) à la ligne 3843 qui correspond au degré de liberté donné ci-dessus.                             !
   !                                                                                                                              !
   ! Risques et conseils :                                                                                                        !
   !    * Si la ligne correspond a un degré de liberté physique, il s'agit probablement d'un mouvement                            !
   !      de corps rigide mal bloqué.                                                                                             !
   !      Vérifiez les conditions aux limites.                                                                                    !
   !      Si vous faites du contact, il ne faut pas que la structure ne "tienne" que par le contact.                              !
   !      Vérifiez également les caractéristiques matériaux (module d'Young, ...).                                                !
   !                                                                                                                              !
   !    * Si la ligne correspond a un degré de liberté de Lagrange, il s'agit sans doute d'une condition                          !
   !      limite redondante.                                                                                                      !
   !      En particulier, il se peut que la relation linéaire surabondante provienne des conditions de contact.                   !
   !      Peut-être devriez vous exclure certains noeuds des conditions de contact                                                !
   !      (mots clés SANS_NOEUD et SANS_GROUP_NO).                                                                                !
   !                                                                                                                              !
   !    * Si le solveur utilisé est LDLT ou MULT_FRONT, vous pouvez utiliser le solveur MUMPS                                     !
   !      car celui-ci est le seul à pouvoir factoriser les matrices qui ne sont pas définies positives.                          !
   !                                                                                                                              !
   !    * Parfois, en parallèle, le critère de détection de singularité de MUMPS est trop pessimiste ! Il reste néanmoins souvent !
   !      possible de faire passer le calcul complet en relaxant ce critère (augmenter de 1 ou 2 la valeur du mot-clé NPREC) ou   !
   !      en le débranchant (valeur du mot-clé NPREC=-1) ou en relançant le calcul sur moins de processeurs.                      !
   !                                                                                                                              !
   !    * Il se peut aussi que ce phénomène soit tout à fait normal avec X-FEM si la fissure passe                                !
   !      très près d'un noeud.                                                                                                   !
   !      Si le nombre de décimales perdues n'est pas trop grand (max 10 décimales),                                              !
   !      vous pouvez relancer le calcul en augmentant le nombre de décimales perdues autorisé :                                  !
   !      mot-clé NPREC du mot clé facteur SOLVEUR.                                                                               !
   !      Sinon, contactez l'équipe de développement.                                                                             !

By looking into the problem a bit more in detail I found that one node which belongs to the symmetry boundary condition (symm) is overconstrained:

 Degré de liberté de Lagrange associé à une relation linéaire entre plusieurs degrés de liberté.
  La relation linéaire a été définie par la commande ayant produit le concept de nom symm.
  La liste des noeuds impliqués dans cette relation linéaire est la suivante:
    Node N1257
    Node N1257
    Node N1257

The "geometry" displayed in the image is a simplification of the real problem, where I cannot replace FACE_IMPO with DNOR=0 since the normal is not the same at every node on the face.

Any idea how can I overcome this problem?

*NOTE* I have already tried to remove the nodes on the shared edge from the support boundary condition, but this leads to the displacement of these nodes in the Z direction (violating the imposed zero displacements on the upper face)

Any help is really appreciated!

#12 Code_Aster usage » Problem JEVEUX_40 when starting dynamic simulation » 2020-08-19 10:49:40

Replies: 1

Hi everyone!

I hope someone can help me to find out the reason for this problem. I got the following error after the execution of DYNA_NON_LINE:

   ! <EXCEPTION> <JEVEUX_40>                                                                 !
   !                                                                                         !
   !      Erreur écriture de l'enregistrement 30191 sur la base : VOLATILE 1                 !
   !      code retour
<I>_EXIT_CODE = 139

Attached you can find the .mess file containing the respective message.

Best regards,

#14 Code_Aster usage » DYNA_VIBRA with cooling rate as load NOT WORKING » 2017-04-26 21:47:20

Replies: 1

Hello, all.

In previous posts I expressed multiples concerns about different issues regarding the same topic, Thermo mechanical couplings.

I have success at performing them calculating the temperature gradient with THER_NON_LINE, then projecting the result on a different mesh to calculate thermal stresses due to thermal shrinkage with MECA_STATIC and STAT_NON_LINE. Now, I want to do the same but with a rate of cooling within the thermal analysis such as:

T(t)=(T0-Tf)*exp(-a*t)+T0  #where "a" is my rate of temperature decrease (T(t) is my boundary condition)

So, I expect in the mechanical analysis to have different stress (probably more in the case of a quicker cooling). This is why I use DINA_VIBRA(TYPE_CALCUL='TRAN',
Doing so, I get results of both but are exactly the same!!

I am not expert performing Dynamic analyses, so I'm not sure if I'm doing it right. Also, printing the results I cannot visualize neither the displacement field nor the strains (EPSI_NOEU), giving me the next warning:

   ! <A> <UTILITAI4_1>                                                                                       !
   !                                                                                                         !
   !  La récupération des chargements concernant le résultat SOL n'est actuellement pas possible.            !
   !  Code_Aster ne peut donc pas vérifier la cohérence des chargements.                                     !
   !                                                                                                         !
   !  Conseil : Si vous utilisez une commande avec une option qui nécessite la redéfinition des chargements, !
   !  il faut vérifier la cohérence des chargements.                                                         !
   !                                                                                                         !
   !                                                                                                         !
   ! Ceci est une alarme. Si vous ne comprenez pas le sens de cette                                          !
   ! alarme, vous pouvez obtenir des résultats inattendus !                                                  !

The only visible fields are SIGM_NOEU and EPME_NOEU.

Does anyone has any hint on this? It would be soooooo much apreciated!

Thanks in advance,

Guillermo Barraza

#15 Re: Code_Aster usage » POURSUITE(); regarding » 2017-04-26 20:43:12

DURAI04 wrote:

Hi all,

I have an two .comm files but while solving its shows that the following error how to rectify this errors

Etape  POURSUITE ligne :  2 fichier :  fort.1 impossible d affecter un type au  !
   ! resultat:                                                                       !
   !  Il n'y a pas de fichier glob.1 ou bhdf.1 dans le répertoire courant.          !
   !                                                                                 !
   ! Conseils:                                                                       !
   !    - Vérifiez que vous avez une base (de type base ou bhdf) dans votre étude. !
   !    - Vérifiez si elle doit être décompressée ou pas.

From what I understand is that Code_Aster can't find glob.1 file, which is where the results from your previous analysis were stored. If you are using ASTK you have to put your .base file from the first run (e.g. study_1.base) as an entry for the next run. This can be done by clicking on the blank box next to D (which corresponds to "DATA"). Then just specify another .base as "R" to store the results from your second analysis. With this should be just fine.


Guillermo Barraza

#16 Code_Aster usage » Contact condition (inequality) » 2017-03-30 01:25:27

Replies: 0

Hi everyone.

I'm running a coupled analysis, thermal and mechanical.

Due to the thermal shrinkage, both bodies (body_1 and body_2, as seen in the attached figure) are going to separate one from the other (body_2 has higher coefficient of thermal expansion). I need to apply a prestress on the external face of body_1 to ensure that it does not separate from body_2, but this force shouldn't make body_1 get closer to body_2 than the initial gap.

Regarding the analysis, I know how to impose contact conditions and run the coupled study. So the question must be:
How can I impose a condition such as:

if g<=g0:  #(where g is the gap and g0 is the initial gap)
    #stop simulation and print prestress
   #keep running simulation

As well, I need to declare that, even though there's an initial gap, the two bodies are initially in contact. Is this done with CONTACT_INIT = 'OUI' in CONTINUE formulation?

Thanks in advance


#17 Re: Code_Aster usage » command IMPR_TABLE » 2017-03-21 19:19:48

cramirez wrote:

Thanks for your answer, you could also say that it is that of logical unit and that means the number 8

The key word UNITE specifies where the file is going to be printed depending on the kind of data you have. Regarding the number, 8 is the default identifier for .resu files. If you are working with ASTK, logic units are useful to print results of the same type and store them in different files.

E.g. You are about to print two tables (IMPR_TABLE) and store the results in two different .resu files. The next thing you do is declare the logic unit in each table:

                      UNITE=8,); #8 is .resu by default
                      UNITE=9,); #9 could also be .resu if defined in astk



#18 Code_Aster usage » PARAMETRIC analysis. Large files stored in /temp. » 2017-03-17 20:41:52

Replies: 0

Hello all.

I've been presented with the problem mentioned above. When running a parametric study in ASTK (5 cases to be precise), the memory consumption of /temp exceeds my total storage capacity (which is just 18 Gb located in root). I don't know the reason of this since I've run it previously and worked, the only difference is that, at the end of my program, I declared some files and print tables on them. I'm not sure what the problem could be.

I provide you a compressed file containing the export and mess files to see the results of all of them.

Thank's in advance,


#19 Re: Code_Aster usage » [SOLVED]DEFI_LIST_INST (METHODE='AUTO' ->NOT working!!!) » 2017-03-17 20:23:23

Thank you for your advises, Richard.

The problem was solved by applying a smooth time-dependent formula for my boundary condition, instead of the function established previously. That made my time stepping less complex accordingly to my case. Anyway, the recommendation is useful for next simulations though.

Best regards,


#20 Re: Code_Aster usage » [SOLVED]DEFI_LIST_INST (METHODE='AUTO' ->NOT working!!!) » 2017-03-07 18:06:13

Sorry for the late reply.

Attached to this post is the .mess file. Hopefully you'll find what I might have overlooked.
I would like to know how, in case of non convergence, DEFI_LIST_INST could determine the division of time steps.
Furthermore, I tried your code but didn't work. So I did some modifications.

Here's an excerpt of mi code:


Thank's in advance

#21 Re: Code_Aster usage » [SOLVED]DEFI_LIST_INST (METHODE='AUTO' ->NOT working!!!) » 2017-03-03 00:12:21

stephane wrote:

Maybe something like that ...

Hello, stephan. Thank you for taking the time to check out my post.

I've tried what you mentioned, however it's still doing the same: It starts with 0.01, then 0.02 and so on, but by the time it gets to 0.05 it diverges. So, the problem must be between 0.04 and 0.05. I want the program to automatically detect when this happens and starts to discretize in smaller steps (eg. [0.04, 0.041, 0.42...]). Any idea on how to achieve this?


#22 Code_Aster usage » [SOLVED]DEFI_LIST_INST (METHODE='AUTO' ->NOT working!!!) » 2017-02-28 23:24:19

Replies: 8

Hello, everyone.

I'm running a NON-Linear simulation using DEFI_LIST_INST and automatic time stepping.
I explicitly need the simulation to pass through some specific times (due to the specification of my boundary conditions). So I established these:

LIST = DEFI_LIST_REEL(VALE=(0, 0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.1, 1, 10, 100,),);

No matter what, I need that the minimum PAS does not go below 0.0025. The solver decided to increase by 0.01 each step (reaching convergence) but by the time it reach the time step 0.05 it diverges. It seems that the solver is ignoring the statement PAS_MINI, since the PAS never decreased.

How can I make the solver to explicitly pass through the points showed above and, at the same time, adapt the time stepping in the process?

Thanks in advance,


#23 Re: Code_Aster installation » CENTOS 7 - code_aster 12.6 » 2016-11-26 01:28:44

stephaneberger wrote:

If I change in the Makefile.inc file /opt/aster/public/scotch-5.1.11_esmumps to /opt/aster/public/scotch-5.1.11, the error on lesmumps, lscotch and lscotcherr disappear

Hello, Stephan.

I'm facing the same problem you had, but didn't understand quite clearly what you changed to make it work. Doesn't the Makefile.inc had to be placed in the mumps-4.10.0_mpi folder and no otherwise?

Hope that you can help me with this.



#24 Code_Aster usage » Help with MECANOLINE2_92 » 2016-11-24 22:44:49

Replies: 0

Helo all.

I had found the next ALARM in a mess file from a Thermo-mechanical coupling:

   ! <A> <MECANONLINE2_97>                                                                                                               !
   !                                                                                                                                     !
   !   -> Les variables de commandes initiales induisent des contraintes                                                                 !
   !      incompatibles :                                                                                                                !
   !      l'état initial (avant le premier instant de calcul) est tel que                                                                !
   !      les variables de commande (température, hydratation, séchage...)                                                               !
   !      conduisent à des contraintes non équilibrées.                                                                                  !
   !                                                                                                                                     !
   !   -> Indications supplémentaires : pour la variable de commande :  TEMP                                                             !
   !      et la composante :  TEMP                                                                                                       !
   !      Valeur maximum de la valeur absolue de ( TEMP - TEMP_REF) : 26.850000 sur la maille : M14182                                   !
   !      Valeur minimum de la valeur absolue de ( TEMP - TEMP_REF) : 26.850000 sur la maille : M2469                                    !
   !                                                                                                                                     !
   !   -> Risque et conseils : dans le cas d'une résolution incrémentale, on ne considère que la variation des variables de commande     !
   ! entre l'instant précédent et l'instant actuel.                                                                                      !
   !      On ne prend donc pas en compte d'éventuelles contraintes incompatibles dues à ces variables de commande initiales.             !
   !      Pour tenir compte de ces contraintes vous pouvez :                                                                             !
   !      - partir d'un instant fictif antérieur où toutes les variables de commande sont nulles ou égales aux valeurs de référence      !
   !      - choisir des valeurs de référence adaptées                                                                                    !
   !                                                                                                                                     !
   !      Pour plus d'informations, consultez la documentation de STAT_NON_LINE (U4.51.03) mot-clé EXCIT et le test FORMA30 (V7.20.101). !
   !                                                                                                                                     !
   !                                                                                                                                     !
   ! Ceci est une alarme. Si vous ne comprenez pas le sens de cette                                                                      !
   ! alarme, vous pouvez obtenir des résultats inattendus !                                                                              !

I have found this post from 2008 saying that was a bug corrected in version 9.3.25 but still happening in 12.4, so maybe I overlooked something. Does anyone have any idea of this alarm?

thanks in advance,


#25 Re: Code_Aster usage » [SOLVED]Open bash window while running ASTK » 2016-11-24 22:26:58

Thanks for your reply, metalfox.

Apparently, there's no problem with ASTK anymore. Although, I will try to run my program with as_run as well.