(U1.03.00) The main principles of operation of Code Aster

From en.wiki.laduga.ru
Jump to: navigation, search


Résumé: One presents here in a summary way the principles of operation of Code_Aster and the main rules of use. This document remains a general description and the player will refer usefully to the other documents, for all the details of use.

1 General principles

Code Aster makes it possible to carry out structural analyses for the phenomena thermal, mechanics, thermomechanical, or thermo-hydro-mechanics coupled, with a or not linear linear behavior, and computations of internal acoustics.

Nonthe linearities relate to the behaviors of the materials (metallurgical plasticity, viscoplasticity, damage, effects, hydration and drying of the concrete,…), large deformation or large rotations and the contact with friction. One will refer to the plate of presentation of Code_Aster for the presentation of the various functionalities.

The standard industrial studies require the implementation of mesh and graphic visualization tools which do not belong to the code. However, several tools are usable for these operations via procedures of application interface integrated into the code.

To make a study, the user must, in general, prepare two data files:

  • the mesh file:
This file defines the geometrical and topological description of the mesh without choosing, at this stage, the type of formulation of the finite elements used or the physical phenomenon to modelize. Some studies can result in using several mesh files.
This mesh file, in general, is produced by commands integrated into Code_Aster, from a file coming from a mesh software used as preprocessor (SALOME, GIBI, GMSH, IDEAS…).
Information contained in this file is specific to Code_Aster. They define conventional entities of the finite element method:
  • nodes: points defined by a name and their Cartesian coordinates in space 2D or 3D,
  • meshes: plane or voluminal named topological figures (not, segment, triangle, quadrangle, tetrahedron,…) to which will be able to apply different element types finished, boundary conditions or loadings.
To improve safety of use and comfort of the modelization and post-processing operations, it is possible to define in the mesh file higher levels of entities, having an unspecified property in common and which will be used directly by their name:
  • nodes groups : named lists of names of nodes,
  • mesh groups : named lists of meshes names.
It will be noted, from now, that all the handled geometrical entities (nodes, meshes, nodes groups, mesh groups) are named by the user and usable constantly by their name (8 characters to the maximum). The user can use this possibility to identify explicitly certain parts of the studied structure in order to facilitate the examination of the results. The numerotation of the entities is never clarified: it is only used internally to point on the values of the various associated variables.
  • the command file : contains the command text which allows:
  • of reading and if required enriching the data of mesh file (or other sources of results external),
  • to affect the data of modelization on the entities of the mesh,
  • to connect various operations of processing: specific computations, postprocessings,
  • to publish the results on various files.
The command text refers to the names of geometrical entities defined in the mesh file. It also makes it possible to define new groups at any moment.

From the data-processing point of view, these two files are ASCII files in free format. Their main features are listed below:

Syntax of the mesh file:

  • length of line restricted with 80 characters,
  • the allowed characters are:
  • 26 tiny capital letters A-Z and the 26 a-z converted automatically in capital letters, except in the texts (provided between quotes),
  • ten figures 0-9 and the signs of representation of the numbers ( + -. ),
  • the character _underscore usable in key words or names,
  • a key must always start with a letter,
  • white space is always a separator,
  • the character % indicates the beginning, until the end of line, of a comment.
  • The other rules of reading are specified in the booklet [U3.01.00]

Syntax of the command file :

  • syntax related to the language Python, making it possible to include instructions of this language
  • character # indicates the beginning, until the end of line, of a comment.
  • The commands must start in column 1, unless they belong to a block indenté (buckles, test)

The other rules of reading are specified in the booklet [U1.03.01].

2 Mesh

2.1 General information

The Aster mesh file can be written (for really elementary meshes) or modified manually with any text editor. This file is read in free format, structured in records or subfiles by imposed keywords.

Various utilities have been developed to facilitate the mesh importation in Code_Aster. There are:

  • the utilities of conversion which allow the conversion of one mesh file produced by another

software package (IDEAS, GIBI, GMSH…) in one mesh file with the Aster format ,

  • the reading command of one mesh file with med format, produced by Salome.

2.2 The Aster mesh file

The structure and the syntax of the Aster mesh file are detailed in the Booklet [U3.01.00].

The Aster mesh file is read from the first line to the first occurrence of a line beginning with the word FIN. This key word is compulsory. Mesh file is structured under - independent files starting with a key word and is finished by the key word imposed FINSF.

This file must at least contain two subfiles:

  • coordinates of all the nodes of the mesh in a cartesian coordinate system 2D (COOR_2D) or 3D (COOR_3D).
  • the description of all meshes (TRIA3, HEXA20, etc…), on which one will affect then physical properties, of the finite elements, boundary conditions or loadings.

It can possibly include nodes groups (GROUP_NO) or meshes groups (GROUP_MA) to facilitate the operations of assignment and post-processing.

It is essential to explicitly create at this stage the meshes located on the borders of application of the loadings and the boundary conditions. Then will be found in the mesh file:

  • meshes of edge of the elements 2D necessary,
  • meshes of face of the elements 3D massive necessary;
  • the mesh groups of associated edge and/or face.

This stress becomes bearable when an application interface is used, which does the work starting from the indications provided during the mesh operation (see documents PRE_IDEAS [U7.01.01] or PRE_GIBI [U7.01.11]).

2.3 The utilities of conversion

These interfaces make it possible to convert the files, with or without format, used by various software packages or codes computer, with the conventional format of the Aster mesh file.

The currently available interfaces are those which make it possible to use the mesh generator IDEAS, the mesh generator GIBI of CASTEM 2000 and the mesh generator GMSH.

2.3.1 The universal file IDEAS

The convertible file is the universal file defined by documentation I-DEAS (see Booklet [U3.03.01]). The recognition of the IDEAS version used is automatic. A universal file IDEAS consists of several independent blocks called “data sets”. Each “data set” is framed by the character string -1 and is numbered. “Data sets” recognized by the application interface are described in the booklet [U3.03.01].

2.3.2 Mesh file the GIBI

The interface is carried out using command PRE_GIBI [U7.01.11]). The convertible file is file ASCII restored by the command TO SAVE FORMAT of CASTEM 2000. The precise description of the interface is given in [U3.04.01].

2.3.3 Mesh file the GMSH

The interface is carried out using command PRE_GMSH [U7.01.31]). The convertible file is the ASCII file restored by command SAVE of GMSH.

2.4 Mesh file with med format

The interface is realized using command LIRE_MAILLAGE (FORMAT=' MED') [U4.21.01]. MED (Modelization and Exchange of Data) is a neutral format of data developed by EDF R&D and French atomic energy agency for the data exchanges between computer codes. Files MED are binary and portable files. Reading a MED file by LIRE_MAILLAGE makes it possible to recover a mesh produced by any other code able to create a file MED on any other machine. This format of data is in particular used for the swapping of mesh and results files between Code_Aster and Salomé or the tool of mesh refinement HOMARD. The accurate description of the application interface is given in [U7.01.21].

2.5 The use of incompatible meshes

Although the finite element method recommends the use of regular meshes, without discontinuity, to obtain a correct convergence towards the solution of the continuous problem, it can be necessary for certain modelizations to use incompatible meshes: on both sides of a border, the meshes do not correspond. The connection of these two meshes is then managed in the command file by the keyword LIAISON_MAIL of command AFFE_CHAR_MECA. This gives the possibility in particular to connect a finely meshed area with another one where a coarse mesh is sufficient.

2.6 The mesh adaptive

From an initial mesh, it is possible to adapt the mesh, to minimize the made mistake, using the macro command MACR_ADAP_MAIL, which calls on the software HOMARD. The adaptive mesh software HOMARD operates on meshes composed of segments, triangles, quadrangles, tetrahedrons, hexahedrons and pentahedrons.

This mesh adaptation occurs after a first computation with Code_Aster. An error indicator will have been computed. According to its value mesh by mesh, HOMARD will modify the mesh. It is also possible to interpolate fields of temperature or displacement at the nodes of the old mesh towards the new one [U7.03.01].

3 Commands

3.1 The command file

The command file contains a set of commands, expressed in a language specific to Code_Aster (which must respect syntax Python). These commands are analyzed and executed by a software layer of Code_Aster called “supervisor”.

3.2 The role of the supervisor

The supervisor carries out various tasks, in particular:

  • a phase of checking and interpretation of the command file,
  • a stage of execution of the interpreted commands.

These tasks are detailed in the document [U1.03.01].

The command file is treated starting from the line where the first call for procedure DEBUT () or procedure POURSUITE () is,to the first occurrence of command FIN (). The commands located before DEBUT () or POURSUITE () and after FIN () are not carried out, but must be syntactically correct.

Syntactic phase of checking:

  • reading and syntactic checking of each command; any error of detected syntax is the object of a message, but the analysis continues,
  • checking that all the concepts used as arguments were declared in a preceding command like product concept of an operator; it is also checked that the type of this concept corresponds to the type required for this argument.

Stage of execution:

the supervisor activates successively the various operators and procedures, which carry out the tasks foreseen.

3.3 The principles and the syntax of the process control language

The modular concept of Code_Aster makes it possible to present the code like a succession of independent commands:

the procedures, which do not produce directly of results, but ensure, amongst other things, the management of the exchanges with the external files, the operators, who carry out an operation of computation or data management and produce a result concept to which the user gives a name.

These concepts represent data structures that the user can handle. These concepts are typified at the time of their creation and will only be used as input argument of the corresponding type.

Procedures and operators thus exchange the necessary information and values via the named concepts.

The complete syntax of the commands and its implications on the drafting of the command file are detailed in the booklet [U1.03.01]. Here an example of a few commands is given (extracted from the example with accompanying notes in [U1.05.00]):

   mall = LIRE_MAILLAGE () 

    mod1 = AFFE_MODELE (MESH = mall, 
                        AFFE=_F (TOUT='OUI', 
                        PHENOMENE='MECANIQUE', 
                        MODELISATION='AXIS'))

    f_y = DEFI_FONCTION (NOM_PARA = “Y”
                         VALE =_F (0. , 20000. , 
                                   4. , 0. )
                        )  

    charg = AFFE_CHAR_MECA_F (MODELE = mod1
            PRES_REP =_F (GROUP_MA = (` lfa', ` ldf'), 
                          PRES = f_y)) 
    .....
    res1 = MECA_STATIQUE (MODELE=mod1,
                         ......
                         EXCIT=_F (LOAD = charg),
                         ….)

    res1 = CALC_CHAMP (reuse=res1, RESULTAT=res1, 
                       MODELE=mod1, 
                       CONTRAINTE= (“SIGM_ELNO”), 
                       DEFORMATION= ('EPSI_ELNO),);

Some general points will be noted, which can be observed on the preceding example:

  • any command starts in first column,
  • the list of the operands of a command is obligatorily between brackets, as well as the lists of elements,
  • a nom_de_concept can appear only once in the text of command like product concept, on the left of the sign = ,
  • the re-use of an existing concept like product concept, is possible only if for the operators specified for this purpose. When this possibility is used (reentering concept), then the command uses the reserved keyword “reuse”.
  • a command is made up of one or several mot_clé or mot_clé_facteur, the latter being themselves composed of a list of mot_clé between brackets and preceded by the prefix _F. In the example suggested, the command AFFE_CHAR_MECA_F uses the mot_clé MODELE

and the mot_clé_facteur PRES_REP, which is composed of both mot_clé GROUP_MA and PRES.

This operation is done:

  • either with crushing of the initial values. For example the factorization in core of a stiffness matrix:
masted = TO FACTORIZE (reuse=matass, MATR_ASSE= masted)
  • that is to say with enrichment of the concept.

3.4 Regulate of overload

a rule of overload usable, in particular for all the operations of assignment, was added to the rules of use of a mot_clé_facteur with several lists of operands:

  • the assignments are done by superimposing the effects of different mot_clé,
  • in the event of conflict, the mot_clé last overrides the precedents.

Example: we want to affect various materials MAT1, MAT2 and MAT3 on certain meshes:

   subdue = AFFE_MATERIAU (MAILLAGE= mon_mail
            AFFE = _F (TOUT = ` OUI', MATER = MAT1),
                   _F (GROUP_MA = ` mail2', MATER = MAT2),
                   _F (GROUP_MA = ` mail1', MATER = MAT3),
                   _F (MESH = (“m7','m8' ), MATER = MAT3))

One starts by meshes assigning material MAT1 to all.

  • Then we assign material MAT2 to the mesh group mail2 which contains the meshes m8, m9 and m10.
  • One assigns finally material MAT3 to the mail1 mesh group (m5, m6 and m7) and to meshes the m7 and m8 , which is source of conflict since the mesh m7 is already part of the mail1 group. The rule of overload will then be observed and one will obtain finally the following material field:
   MAT1 : meshes m1 m2 m3 m4
   MAT2 : meshes m9 m10
   MAT3 : meshes m5 m6 m7 m8

the progressive effect of the various assignments of material is illustrated in the table below.

Name of the mesh Material field after the 1st assignment Material field after the 2nd assignment Material field after the 3rd assignment Final material field
m1 MAT1 MAT1 MAT1 MAT1
m2 MAT1 MAT1 MAT1 MAT1
m3 MAT1 MAT1 MAT1 MAT1
m4 MAT1 MAT1 MAT1 MAT1
m5 MAT1 MAT1 MAT3 MAT3
m6 MAT1 MAT1 MAT3 MAT3
m7 MAT1 MAT1 MAT3 MAT3
m8 MAT1 MAT2 MAT2 MAT3
m9 MAT1 MAT2 MAT2 MAT2
m10 MAT1 MAT2 MAT2 MAT2

3.5 Regulates remanence

The rule of preceding overload must be supplemented by another rule to specify what occurs when one can affect several quantities for each occurrence of a key word factor.

   CHMEC1=AFFE_CHAR_MECA ( MODELE=MO, 
          FORCE_INTERNE= (  _F (TOUT = “OUI”, FX = 1. ),
                            _F (GROUP_MA = “GM1”, FY = 2.),
                         )) 

The rule of overload says that the second occurrence of FORCE_INTERNE overloads the first.

But what is the value of FX on a mesh belonging to GM1 ? Was it erased by the second occurrence?

If only the rule of overload is observed, FX is not defined on GM1. The rule of remanence makes it possible to preserve the value of FX. If the rule of remanence is observed, FX preserves the value affected as a preliminary. All the elements of the model have a value for FX whereas the elements of GM1 have a value for FX and FY.

3.6 Bases memory associated with a study

Code_Aster rests, for the management of all data structures associated with the various concepts handled, on library JEVEUX. This latter manages the memory space required by the user at the time of the request for execution (memory parameter expressed in Mégaoctets). This space is frequently insufficient to store all data structures in central memory. The library then manages the exchanges between central memory and the auxiliary storages on files.

During its creation by the code each entity is affected at a direct access file. This file can be regarded as a data base, since it contains, at the end of the execution, the directory (names and attributes) which can exploit all the segments of values that it contains.

Code_Aster uses several data bases:

  • the data base GLOBALE, which contains all the concepts produced by the operators, as well as the content of certain catalogues on which the concepts lean; the file associated with this base allows the later continuation of a study. It must thus be managed by the user.
  • the other data bases, used only by the Supervisor and the operators, during an execution, do not require a particular intervention of the user.

To make a study is to ask for the series of several commands:

  • procedures to exchange files with the external world,
  • of the operators to create product concepts as course of operation of modelization and computation.

The commands corresponding to this sequence of operations can be realized in various ways, starting from the single executable modulus of Code_Aster :

  • in only one sequential execution, without intervention of the user,
  • by splitting the study in several successive executions, with re-use of the former results; from the

second execution, the access to data base is done with the procedure continuation (POURSUITE); at the time of a continuation, the last command can be repeated if it stopped prematurely (lack of time, incomplete or incorrect data detected in stage of execution,…).


U1.03.00 1.png


To manage these possibilities, it will be noted that three commands play a central role. They correspond to the procedures activating the supervisor:

  • debut () compulsory for the first execution of a study,
  • POURSUITE () compulsory from the second execution of a study,
  • FIN () compulsory for all the executions.

For a given study, one can subject command files having the following structure: Note:

  • Command INCLUDE makes it possible to include in a flood of commands the contents of

another command file. This in particular allows to preserve a readable file of the main commands and to put in annexed files bulky digital data (ex: definition of functions).

  • The command files can be cut out in several files which will be executed one after the other,

with intermediate backup of data base. For that, it is necessary to define the successive command files, whose suffix will be: .com1 , .com2 ,…, .com9. The executions of these files are connected. The data base of the last correct execution is preserved.

3.7 With the definition of the values Substitution

3.7.1 of values It

Helps is possible to parameterize a command file.

For example:

    Eptub = 26.187E-3
 
    Rmoy = 203.2E-3

    Rext = Rmoy+ (EPtub/2)

    will cara = AFFE_CARA_ELEM (MODELE = model
                BEAM =_F ( GROUP_MA = all, SECTION: “CERCLE”, 
                           CARA = (“R”, “EP”), VALE = (Rext, EPtub)))

3.7.2 Functions of one or more parameters

It is also often necessary to use quantities functions of other parameters. Those can be:

  • either defined on an external file read by command LIRE_FONCTION.
  • either defined in the command file by:
  • DEFI_CONSTANTE which produces a concept function with only one constant value,
  • DEFI_FONCTION which produces a concept function for a quantity function of a real parameter,
  • DEFI_NAPPE which produces a concept function for a list of functions of the same quantity, each element of the list corresponding to a value of another real parameter. The concept produced by these operators is of type function and can only be used as argument of operands which accept this type. The operators accepting an argument of type function have as a suffix F (ex: AFFE_CHAR_MECA_F). In this case the functions are defined point by point, with a linear interpolation by default, therefore affine piecewise.

The functions created are discrete arrays of the quantities specified at the creation. During a search for value, according to the specified characteristics, one proceeds by direct search or interpolation in the table (linear or logarithmic). One can specify, during the creation of the function, the prolongation out of the field of definition of the table, with various rules, or prohibit it.

  • or defined using their analytical statement by the operator FORMULE. For example:
 Omega = 3,566 ;

 linst = (0. , 0.01,0.02,0.03,0.04,0.05,0.06,0.07,0.08,0.09,0.10,0.20,0.40)

 F = FORMULA (VALE = '''COS (OMEGA*INST)''')
 F1=CALC_FONC_INTERP (FONCTION=F, VALE_PARA= linst, 
                      NOM_RESU='ACCE”,)


The analytical function$ F(t)=cos(\Omega t) $ are then calculated by CALC_FONC_INTERP for times of the list linst list of times T.

3.8 How to write its command file with EFICAS?

To write a command file of Code_Aster, most immediate consists starting from an example already written by others. In particular, all the tests of Code_Aster often constitute a good starting base for a new modelization. They are documented as documentation of validation. But there is better: tools EFICAS make it possible to write in an interactive and convivial way its command file, by proposing for each command the list of the possible keywords by checking syntax automatically, and by giving access to the documentation of the Instruction manual (booklets [U4] and [U7]).

4 The great stages of a study

The great stages of a study are in the general case:

  • the preparation of the work, which finishes after the reading of the mesh,
  • the modelization during which are definite and affected all the properties of the finite elements and of the materials, the boundary conditions and the loadings,
  • computation can then be carried out by the execution of total methods of resolution [U4.5-], which are possibly based on commands of computation and assembly of matrix and vectors [U4.6-]
  • the operations of postprocessings complementary to computation [U4.8-],
  • operations of printing of the results [U4.9-]
  • operations of exchange of results with other software (graphic visualization for example) [U7.05-]

Another way of using Code_Aster consist in exploiting tools trades, available in the code in the form of MACRO_COMMANDES : let us quote for example the dedicated tools:

  • ASCOUF (modelization of fissured elbows or elbows with under-thickness),
  • ASPIC (modelization of or not fissured fissured bypasses),

4.1 To start the study and to acquire the mesh

One will not reconsider here the possible fragmentation of the command file, which was presented in a preceding paragraph. The first executable command is:

debuts ( ) 

the argument of this command are useful only for the maintenance actions or case of very large studies.

For the reading of the mesh, coming from an external mesh software, one can operate in two ways:

  • convert the file of a software package into a file with the Code_Aster format by an execution separated, which possibly allows to modify it manually and to preserve it:
debut ( )
PRE_IDEAS ( )
FIN ( )
the normal study will be able to then begin for example by:
debut ( )
my = LIRE_MAILLAGE ( )
  • to convert the file right before the lira:
debut ( )
PRE_IDEAS ( )
my = LIRE_MAILLAGE ( ) 

4.2 To assign data of modelization to the mesh

To build the modelization of a mechanical, thermal or acoustic problem, it is essential to assign to the topological entities mesh:

  • a model of finite element,
  • properties of the materials (constitutive law and parameters of the model),
  • characteristics geometrical or mechanical complementary,
  • boundary conditions or loadings.

These assignments are made by various operators the name of which is prefixed by AFFE_. The syntax of these operators and the way they operate use the easiness brought by the rules already mentioned previously on the use of the keywords factor.

4.2.1 Definition of a field of assignment

to carry out an assignment, it is essential to define a field of assignment per reference to the names of the topological entities defined in the file mesh. Five keywords are usable for that, according to the specification of the operator:

  • to refer to all the mesh by TOUT= “YES”
  • to assign to meshes by MAILLE= (list of names of meshes)
  • assigning to mesh groups by GROUP_MA= (list of names of mesh groups)
  • to assign to nodes by NOEUD= (list of names of nodes)
  • to assign to nodes groups by GROUP_NO= (list of names of nodes groups)

4.2.2 To affect the type of finite element

On meshes of studied structure, which are at this stage only topological entities, it is essential to affect:

  • one or more phenomena to study: “MECANIQUE”, “THERMIQUE”, “ACOUSTIQUE”;
  • a model of finite element compatible with the topological description of the mesh. This

assignment induces an explicit list of degrees of freedom on each node and a model of interpolation in the element.

The operator used for this assignment is AFFE_MODELE [U4.41.01], which can be called several times on the same mesh. It uses the rule of overload.

Note :

For a study with several phenomena ( ' MECANIQUE' , ' THERMIQUE' ), it is essential to build a model for each phenomenon, by as many calls to AFFE_MODELE . On the other hand, for a given computation (mechanical, thermal,…) one needs one and only one model.

To know the characteristics of the various finite elements available, one will refer to the booklets [U2-], and [U3-].

4.2.3 To affect characteristics of materials

It is necessary to assign to this stage of the characteristics of material, and the associated parameters, with each finite element of the model (except for the discrete elements defined directly by a stiffness matrix, of mass and/or damping). In other words, DEFI_MATERIAU is used to define a material and AFFE_MATERIAU is used to define a material field by association of the mesh. For a given computation, one needs one and only one material field.

The validated characteristics of the material catalogue can also be used by procedure INCLUDE_MATERIAU [U4.43.02].

A certain number of models of behavior are available: elastic, elastic orthotropic, thermal, acoustic, elastoplastic, elastoviscoplastic. Let us note that it is possible to define several characteristics of materials for the same material: elastic and thermal, elastoplastic, thermoplastic,…

4.2.4 element types To assign characteristics to

the elements During the use of some, for the “MECHANICAL” phenomenon, the geometrical definition deduced from the mesh does not make it possible to describe them completely.

The missing characteristics have to be assigned to the meshes:

  • for shells : the constant thickness on each mesh and a reference of reference for the representation of the stress state,
  • for the beams, bars and pipes: characteristics of the cross section, and possibly orientation of this section around the neutral fiber.

These operations are performed by the operator AFFE_CARA_ELEM [U4.42.01]) which uses, to simplify the command 's drafting, the rule of overload.

Another possibility is offered by this operator: that to introduce, directly in the model, of the stiffness matrixes , mass or damping on meshes POI1 (or nodes) or meshes SEG2. These matrixes correspond to element types finished discrete to 3 or 6 degrees of freedom per node DIS_T or DIS_TR which must be affected at the time of the call to operator AFFE_MODELE.

4.2.5 To affect the boundary conditions and the loadings

These operations are, in general, essential. They are carried out by several operators the name of which is prefixed by AFFE_CHAR or CALC_CHAR. On the same model, one will be able to carry out several calls to these operators to define during the study the boundary conditions and/or the loadings.

The operators used differ with the phenomenon:

“MECHANICAL” AFFE_CHAR_CINE
 AFFE_CHAR_MECAdonnées of the real type only
 AFFE_CHAR_MECA_Fdonnées of type “
THERMAL” function AFFE_CHAR_THERdonnées of the real type only
 AFFE_CHAR_THER_Fdonnées of type function
“ ACOUSTIQUE'AFFE_CHAR_ACOUdonnées of the real type only

Moreover, one can establish the seismic loading to carry out a computation of response moving relative motion compared to the bearings, with L” helps CALC_CHAR_SEISME of the command.

The boundary conditions and loadings can be defined according to their nature:

  • with the nodes,
  • on meshes of edge (edge or face) or meshes support of finite elements, created in the file

mesh. On these meshes, operator AFFE_MODELE has affected the necessary types of finite elements.

For a detailed definition of these operators' operands and the rules of orientation of the meshes support (global, local or unspecified reference) one will refer to the documents [U4.44.01], [U4.44.02], and [U4.44.04].

The boundary conditions can be dealt with in two ways:

  • by “elimination” of the degrees of freedom imposed (for linear mechanical models

implementing only kinematical boundary conditions (locked degrees of freedom) without linear relation). In this case the boundary conditions will be defined using command AFFE_CHAR_CINE.

  • by dualisation [R3.03.01]. This method, thanks to its greater generality, makes it possible to

treat all the types of boundary conditions (imposed degree of freedom, linear relations between degrees of freedom,…) ; this method results in adding 2 LAGRANGE multipliers for each d. o. ⇌

imposed or for each linear relation. ⇌ Each concept produced by a call to these operators, of type AFFE_CHAR, corresponds to a system of boundary conditions and loadings indissociable. In the computation commands, these concepts can be incorporated by providing for the operands CHARGE a list of concepts of this type.

4.3 To carry out computations by global commands

4.3.1 Thermal analysis

To compute: it (S) field (S) of temperature corresponding to a or not linear linear thermal analysis:

  • steady (time 0),
  • evolutionary times of computation are specified by an as a preliminary definite list of realities

the commands to be used are:

  • THER_LINEAIRE for a linear analysis [U4.54.01],
  • THER_NON_LINE for a nonlinear analysis [U4.54.02],
  • THER_NON_LINE_MO for a problem of mobile loads in permanent mode [U4.54.03].

Computations of the elementary and assembled matrices and vectors necessary to the implementation of the methods of resolution are managed by these operators.

4.3.2 Static analysis

To compute: mechanical evolution of a structure subjected to a list of loadings:

  • MECA_STATIQUE [U4.51.01]: linear behavior, with superposition of the effects of each

loading,

  • MACRO_ELAS_MULT [U4.51.02]: linear behavior, by distinguishing the effects of each loading,
  • STAT_NON_LINE [U4.51.03]: quasi-static evolution of a structure subjected to a load history in small or large transformations, made of a material the behavior of which is linear or not linear, with possibly taking into account contact and friction.

If this mechanical computation corresponds to a study of thermoelasticity, one will refer to one time of the thermal computation already carried out. If the material was defined with characteristics depending on temperature, they are interpolated at the temperature corresponding to the required time of computation.

For thermohydromecanic coupled problems, the operator STAT_NON_LINE is used to solve simultaneously the 3 problems thermal, hydraulics and mechanics. Computations of the elementary and assembled matrices and vectors necessary to the implementation of the methods of resolution are managed by these operators.

4.3.3 Modal analysis

To compute: eigen modes and eigenvalues of the structure (corresponding to a vibratory problem or a problem of buckling).

  • MODE_ITER_SIMULT [U4.52.03]: computation of the eigen modes by simultaneous iterations; the clean eigenvalues and vector are real or complex,
  • MODE_ITER_INV [U4.52.04]: computation of the eigen modes by inverse iterations; the clean eigenvalues and vector are real or complex,
  • MACRO_MODE_MECA [U4.52.02]: the modal analysis reduces by cutting out the interval automatically of frequency under intervals,
  • MODE_ITER_CYCL [U4.52.05]: computation of the eigen modes of a structure with cyclic repetitivity starting from a base of real eigen modes.

As a preliminary these four operators require the computation of the assembled matrices [U4.61-].

4.3.4 Dynamic analysis

To compute: the dynamic response, linear or not linear, of structure. Several operators are available. Can be quoted for example:

DYNA_LINE_TRAN [U4.53.02]: temporal dynamic response of a linear structure subjected to a transitory excitation, DYNA_LINE_HARM [U4.53.02]: dynamic response complexes of a linear structure subjected to a harmonic excitation, DYNA_TRAN_MODAL [U4.53.21]: transient dynamic response in generalized coordinates by modal recombination.

As a preliminary these three operators require the computation of the assembled matrices [U4.61-].

DYNA_NON_LINE [U4.53.01]: temporal dynamic response of a nonlinear structure subjected to a transient excitation, computing the assembled matrices too.

4.4 Results

Results produced by the operators realizing of computations by finite elements [U4.3-], [U4.4-] and [U4.5-] are of two principal types:

  • either of the cham_no type or cham_elem (by node or element) when it acts operators producing one field (for example TO SOLVE),
  • or of the type RESULTAT to be strictly accurate which gathers sets of fields.

In a concept of the RESULTAT type a field is identified:

  • by a variable of access which can be:
  • a simple sequence number referring to the order in which the fields were arranged,
  • a parameter preset according to the type of result concept:
  • frequency or number of mode for a RESULTAT of the mode_meca type,
  • time for a RESULTAT of the evol_elas type, temper, dyna_trans or evol_noli.
  • by a symbolic field name referring to the type of the field: generalized displacement, velocity, stress state, forces,…

Besides the variables of access, other parameters can be attached to a kind of result concept.

The various fields are incorporated in a result concept:

  • that is to say by the operator which created the concept, a global command (MECA_STATIQUE, STAT_NON_LINE,…) or a simple command (MODE_ITER_SIMULT, DYNA_LINE_TRAN,…),
  • that is to say during the execution of a command which makes it possible to add a computation option in the form of a field by element or of a field at nodes (CALC_CHAMP); it is then said explicitly that one enriches the concept:
resul = operator (reuse=resu1, RESULTAT = resul…) ;

4.5 To exploit the results

All the preceding commands have building permit various concepts which are exploitable by operators of postprocessing of computations:

  • general operators of postprocessing (see booklet [U4.81]), for example CALC_CHAMP, POST_ELEM, POST_RELEVE_T,
  • operators of fracture mechanics (see booklet [U4.82]), for example CALC_G,
  • metallurgy operator: CALC_META,
  • static mechanical postprocessing (see booklet [U4.83]), for example POST_FATIGUE, POST_RCCM,
  • dynamic mechanical postprocessing (see booklet [U4.84]), for example POST_DYNA_ALEA, POST_DYNA_MODA_T.
  • operators of extraction:
  • of a field in a result concept CREA_CHAMP [U4.72.04],
  • of a field in generalized coordinates for a dynamic computation with modal base RECU_GENE [U4.71.03],
  • of a function of evolution of a component from a result concept RECU_FONCTION [U4.32.03],
  • and of restitution of a dynamic response in physical base REST_GENE_PHYS [U4.63.31],
  • an operator of postprocessing of functions or three-dimensions functions CALC_FONCTION which allows searches of peaks, extremums, linear combinations,… [U4.32.04].

Lastly, two procedures IMPR_RESU [U4.91.01] and IMPR_FONCTION [U4.33.01] allow the printing and possibly the creation of exploitable files by other software packages, in particular regarding graphic visualization. One will retain in particular graphic visualization by IDEAS, GMSH, or GIBI whatever mesh tool used at the beginning.

5 Print files and error messages

Code_Aster writes the relative information with computation in three files whose meaning is the following one.

File Contained
ERREUR Errors met during the execution
MESSAGE Information on the course of computation.

Repetition of the provided command file and its interpretation by Aster. Execution time of each command. Messages “system”

RESULTAT Only the expressly written results required at the request of the user and the messages d'error

Of other files are used for the interfaces with the programs of graphic examination. There exists various types of ERREUR messages. The transmitted messages will be directed only according to their type:

Code Standard/fatal message Output files
F message d'error, the execution stops after various printings. The concept created by the current command is lost. Nevertheless, the concepts produced previously are validated and GLOBAL data base is saved. Such a message is used in the frame of detection of a serious error which cannot allow the normal continuation of a Code_Aster command. ERREUR
MESSAGE
RESULTAT
E message d'error, the execution continues a little bit: this kind of message makes it possible to analyze a series of errors before the program stops. The emission of a message of the <E> type is always followed by the emission of a message of the <F> type. The concepts produced are validated and the GLOBAL data base is available for a POURSUITE. ERREUR
MESSAGE
RESULTAT
S message d'error, the concepts created during the execution, including of the command current, are validated by the supervisor, the execution stops with “clean” closing of the global database. It is thus reusable in POURSUITE. This message makes it possible in particular to be secured against a problem of convergence or time during an iterative process. ERREUR
MESSAGE
RESULTAT
A alarm message. The number of alarm messages is restricted automatically with 5 identical successive messages. It is recommended to the users who have messages of type A “to repair” their command file (or their mesh file) to make them disappear. MESSAGE
RESULTAT
I message of information of the supervisor MESSAGE

NB: The exceptions behave exactly like <S> errors. They are in fact <S> errors adapted to a typical case.

References

http://www.code-aster.org/V2/doc/default/en/man_u/u1/u1.03.00.pdf