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 Python syntax). These commands are analyzed and executed by a Code_Aster software layer called a « supervisor ».
3.2. The role of the supervisor#
The supervisor performs a variety of tasks, including:
a**verification phase* and interpretation of the command file,
a**execution phase* of the commands interpreted.
These tasks are detailed in the [U1.03.01] document.
The command file is processed from the line where the first call to the DEBUT () procedure or to the POURSUITE () procedure is located, and up to the first occurrence of the FIN () command . Commands before DEBUT () or POURSUITE () or () and after FIN () ** are not executed, but must be syntactically correct).
Syntactic check phase:
reading and syntactic checking of each command; any syntax error detected is the subject of a message, but the analysis continues, |
check that all the concepts used as arguments were declared in a previous command as the product concept of an operator; we also check that the type of this concept corresponds to the type requested for this argument. |
Execution phase:
the supervisor activates the various operators and procedures in succession, who carry out the planned tasks. |
3.3. The principles and syntax of the command language#
The modular design of*Code_Aster* allows code to be presented as a suite of independent commands:
the procedures, which do not directly produce results, but ensure, among other things, the management of exchanges with external files, |
the operators, who perform a data management or calculation operation and produce a concept result to which the user gives a name. |
These concepts represent data structures that the user can manipulate. These concepts are typed at the time of their creation and can only be used as input arguments of the corresponding type.
Procedures and operators therefore exchange the necessary information and values through the named concepts.
The complete syntax of the commands and its implications for writing the command file are detailed in the paper [U1.03.01]. One gives here an example of some commands (taken from the example commented in [U1.05.00]):
mail= LIRE_MAILLAGE () |
mod1 = AFFE_MODELE (MAILLAGE = mail, |
AFFE =_F (TOUT =” OUI “, |
PHENOMENE =” MECANIQUE “, |
MODELISATION =” AXIS “))) |
f_y = DEFI_FONCTION (NOM_PARA = “Y” |
VALE =_F (0., 20000. , |
4., 0.) |
) |
load = AFFE_CHAR_MECA_F (MODELE = mod1 |
PRES_REP =_F (GROUP_MA = (“lfa”, “pdf”), |
PRES = f_y)) |
… |
res1 = MECA_STATIQUE (MODELE =mod1, |
… |
EXCIT =_F (CHARGE = loaded), |
…) |
res1 = CALC_CHAMP (reuse=res1, RESULTAT =res1, |
MODELE =mod1, |
CONTRAINTE =( “SIGM_ELNO”), |
DEFORMATION =( “EPSI_ELNO),); |
We will note some general points, which can be observed in the previous example:
all orders start in the first column,
the list of operands of a command is necessarily in brackets, as well as the lists of elements,
a concept name can only appear**once* in the order text as a product concept, to the left of the \(\text{=}\) sign,
reuse of an existing concept as a product concept is only possible for operators specified for this purpose. When using this possibility (reentering concept), the command then uses the reserved keyword « reuse ».
a command is composed of one or more keyword or factor_keyword, the latter being themselves composed of a list of keywords in brackets and preceded by the prefix _F. In the example proposed, the command AFFE_CHAR_MECA_F uses the keyword MODELE and the key_factor keyword PRES_REP, which is composed of the two keywords GROUP_MA and PRES.
This operation is done:
or with overwriting the initial values. As an example, let’s mention the factorization in place of a stiffness matrix:
matass = FACTORISER (reuse=matass, MATR_ASSE = matass)
or with enrichment of the concept.
3.4. Overload rule#
An overload rule that can be used, especially for all assignment operations, has been added to the rules for using a factor_keyword with several operand lists:
assignments are made by superimposing the effects of the different keywords,
in case of conflict, the last keyword takes precedence over the previous ones.
Example: we want to assign different materials MAT1, MAT2 and MAT3 to certain meshes:
subdue = AFFE_MATERIAU (MAILLAGE = my_email
AFFE = (_F (TOUT = 'OUI', MATER = MAT1),
_F (GROUP_MA = “mail2”, MATER = MAT2), _F (GROUP_MA = “mail1”, MATER = MAT3), _F (MAILLE = (“m7”, “m8”), MATER = MAT3)))
We start by assigning material MAT1 to all the meshes.
Material MAT2 is then assigned to the group of elements mail2 which contains, the meshes m8, m9 and m10.
Finally, material MAT3 is assigned to the group of elements mail1 (m5, m6 and m7) and to the meshes m7 and m8, which is a source of conflict since the mesh m7 is already part of the mail1 group. The overload rule will then be applied and the following material field will finally be obtained:
MAT2: m9 m10 mesh MAT3: meshes m5 m6 m7 m8
The gradual effect of different material assignments is illustrated in the table below.
Mesh name |
Material field after 1st assignment |
Material field after 2nd assignment |
Material field after 3rd assignment |
Final material field |
|
m1 |
|
|
|
|
|
m2 |
|
|
|
|
|
m3 |
|
|
|
|
|
m4 |
|
|
|
|
|
m5 |
|
|
|
|
|
m6 |
|
|
|
|
|
m7 |
|
|
|
|
|
m8 |
|
|
|
|
|
m9 |
|
|
|
|
|
m10 |
|
|
|
|
3.5. Remanence rule#
The previous overload rule must be supplemented by another rule to specify what happens when you can assign multiple quantities for each occurrence of a factor keyword.
For example:
CHMEC1 = AFFE_CHAR_MECA (MODELE =MO,
FORCE_INTERNE =(
_F (TOUT = “OUI”, FX = 1.),
_F (GROUP_MA = “GM1”, FY = 2. ),
))
The overload rule tells us that the second occurrence of FORCE_INTERNE overrides the first.
But what is FX worth on a mesh belonging to GM1? was it erased by the second occurrence?
If the only overload rule is applied, FX is not set to GM1.
The remanence rule allows the value of FX to be maintained.
If the remanence rule is applied, FX maintains the value previously assigned. All elements in the model have a value for FX and the elements of GM1 have a value for FX and FY.
3.6. Memory bases associated with a study#
Code_Aster relies, for the management of all the data structures associated with the various concepts manipulated, on the JEVEUX library. It takes care of the management of the memory space requested by the user during the execution request (Memory parameter expressed in Megabytes). This space is often insufficient to keep all the data structures in central memory. The library then takes care of the management of exchanges between the central memory and auxiliary file memories.
Each entity is assigned, when created by the code, to a direct access file. This can be considered as a database, since it contains, at the end of execution, the directory (names and attributes) which makes it possible to use all the value segments it contains.
Code_Aster uses several databases:
the GLOBALE database, which contains all the concepts produced by the operators, as well as the content of certain catalogs on which the concepts are based; the file associated with this database allows the subsequent continuation of a study. It must therefore be managed by the user.
the other databases, used only by the Supervisor and the operators, during an execution, do not require any particular user intervention.
Carrying out a study means asking for several orders to be linked together:
procedures for exchanging files with the outside world,
operators to create product concepts as modeling and calculation operations progress.
The commands that correspond to this sequence of operations can be carried out in various ways, using the unique executable module of*Code_Aster*:
in a single sequential execution, without user intervention,
by splitting the study into several successive executions, with reuse of previous results; from the second execution, access to the database is done in**continuation*; during a continuation, you can request the last order again, if it was interrupted prematurely (lack of time, incomplete or incorrect data detected during the execution phase,…).
To manage these possibilities, it should be noted that three commands play a key role. These are the ones that correspond to the procedures that activate the supervisor:
|
mandatory for the first execution of a study, |
|
mandatory from the second execution of a study, |
|
required for all executions. |
For a given study, command files with the following structure can be submitted:
Remarks:
The command INCLUDEpermet to include the contents of another batch file in a batch stream. In particular, this makes it possible to keep a readable main command file and to place large numerical data in attached files (e.g. definition of functions) .
Command files can be divided into several files that will be executed one after the other, with intermediate backup of the database. To do this, you must define the successive command files, whose suffix will be: .com1, .com2,…, .com9. The executions of these files are carried out in succession. The database from the last run that ended successfully is retained.
3.7. Help in defining values#
3.7.1. Substitution of values#
It is possible to configure a command file.
For example:
Eptub = 26.187E-3
Romy = 203.2E-3
Text = Emoy+ (EPtub /2)
cara = AFFE_CARA_ELEM (MODELE = model
POUTRE =_F (GROUP_MA = everything, SECTION: “CERCLE”,
CARA = (“R”, “EP”), VALE = (Text, EPtub)))
3.7.2. Functions of one or more parameters#
It is also often necessary to use quantities that are a function of other parameters.
These can be:
be set to an external file read by the LIRE_FONCTION command.
be defined in the command file by:
DEFI_CONSTANTE which produces a concept function with a single constant value,
DEFI_FONCTION which produces a function concept for a quantity that is a function of a real parameter,
DEFI_NAPPE which produces a function concept for a list of functions of the same magnitude, each element in the list corresponding to a value of another real parameter.
The concept produced by these operators is of a function type and can only be used as arguments to operands that accept this type. Operators that accept a function argument have the suffix F (ex: AFFE_CHAR_MECA_F). In this case, the functions are defined point by point, with linear interpolation by default, and therefore refined piecewise.
The functions created are discrete tables of the quantities specified at creation. During a value search, we proceed according to the specified characteristics, by direct search or by interpolation in the table (linear or logarithm). When creating the function, you can specify the extension outside the domain of definition of the table, with various rules, or prohibit it.
be defined using their analytic expression by the operator FORMULE. For example:
omega = 3.566;
linst = (0., 0.01, 0.02, 0.02, 0.03, 0.03, 0.03, 0.04, 0.04, 0.05, 0.06, 0.07, 0.08, 0.09, 0.09, 0.10, 0.10, 0.20, 0.40)
F = FORMULE (VALE = « “COS (OMEGA * INST) »”)
F1= CALC_FONC_INTERP (FONCTION =F, VALE_PARA = link,
NOM_RESU =” ACCE “,)
The analytical function \(F(t)\mathrm{=}\mathrm{cos}(\Omega t)\) is then calculated by CALC_FONC_INTERP for the times in the list linst list of times t.
3.8. How do you write your order file with AsterStudy?#
To write a Code_Aster command file, the most immediate way is to start with an example already written by others. In particular, the set of Code_Aster tests often provide a good starting point for new modeling. They are documented as validation documentation.
But there is better: the AsterStudy tool allows you to write your command file in an interactive and user-friendly way, by offering access to the Code_Aster tests available, and for each command the list of possible keywords by automatically checking the syntax, the available concepts, by automatically verifying the syntax, the available concepts, by allowing you to visualize on the mesh the entities used, and by giving access to the documentation of the User Manual (fascicles [U4] and [U7]]).