Microsoft Word - D00301a. Doc.

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
1/16
Organization (S): EDF/IMA/MN
Handbook of Descriptif Informatique
D0.03 booklet: Structure
D0.03.01 document
General architecture of Code_Aster
Summary:
One gives in this document an outline of the three ideas which structure in an important way the software
Aster:
· The supervisor of execution,
· The manager of memory JEVEUX,
· concept of calculation elementary.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
2/16
Contents
1 Introduction ...................................................................................................................................... 3
2 general Architecture of routines FORTRAN ................................................................................. 5
3 Architecture of the catalogs ............................................................................................................. 6
3.1 Catalogs of commands ....................................................................................................... 7
3.2 Catalogs of finite elements ....................................................................................................... 7
4 Superviseur of execution .............................................................................................................. 8
4.1 General information ................................................................................................................................ 8
4.2 General operation of Superviseur ................................................................................... 8
4.3 Ask execution of the commands ..................................................................................... 9
4.4 Commands “Supervisor” .................................................................................................... …. 9
5 JEVEUX and Structuration of Données .......................................................................................... 11
5.1 Administrative JEVEUX of objects ................................................................................................. 11
5.1.1 What an object JEVEUX?..................................................................................... 12
5.1.2 Dynamic allocation ..................................................................................................... 12
5.1.3 Virtual memory ............................................................................................................ 12
5.1.4 Writing and reading on disc .......................................................................................... 12
5.2 Structuring of Données ...................................................................................................... 13
6 elementary Calculations ..................................................................................................................... 14
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
3/16
1 Introduction

Code_Aster
is made up various “modules” which one can classify in:
· program main FORTRAN 77,
· routines FORTRAN 77 (subroutine or function),
· functions C,
· routines CAL (CRAY assembling language),
· catalogs.
The whole of the texts of these modules constitutes the source of Aster (approximately 400.000 lines).
catalogs are textual files which parameterize certain programs: mainly the analyzer
elementary commands and calculations (within the meaning of the finite element method).
The functions C carry out certain impossible tasks “system” in FORTRAN 77: allowance
dynamics, measurement of time,…
Routines CAL were written to optimize performances (CPU) of the method of resolution
linear systems by Gradient Conjugué.
If the few functions C and routines CAL are forgotten, we see that the Aster program is
constituted of:
· a few hundreds of catalogs,
· a few thousands of routines FORTRAN 77.
The goal of this document is to help “to find itself” in this great number of modules: only for
FORTRAN, we calculated that the tree of complete call of the Code_Aster program was written
on more than 6.108 lines, which excludes to give it in appendix!
How, under these conditions, to identify the sources relating to a given functionality?
Where to insert a new functionality?
A form of answer to these 2 questions is in the general architecture of the code which was selected with
beginning of Projet (07/89) and which was not called into question since.
This architecture can be summarized about in three ideas:
1) Code_Aster can be seen like a whole of independent commands that the user
connect with its liking,
2) these commands exchange named objects (“concepts”) which are them same
composed of objects JEVEUX,
3) Code_Aster being a code of finite elements, concept of calculation “elementary” (i.e made by one
finite element) is strictly codified because it constitutes to some extent the “core” of
numerical method.
Note:
The first 2 ideas are very general and could be used as architecture with the many ones
software out of the field of the finite elements.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
4/16
They are these three ideas that we will develop in the following paragraphs:
1) is identified about so that one calls Superviseur of execution [§4],
2) is possible thanks to the manager of memory JEVEUX and Structuration of Données
[§5],
3) corresponds to the parameterization of elementary calculations and the existence of the routine
CALCUL [§6].
Note:
· idea 2 structure not the code strictly speaking, but it makes it possible to carry out 1,
· if these three ideas strongly structure the code, they also form the “yoke” of
programming: one cannot withdraw oneself from it. The remainder of the programming is with little
close free,
· the implementation of idea 3, in addition to the fact that it structure a large volume of code
(19000 lines of catalogs and 70000 lines of FORTRAN), a certain number solidifies of
essential notions of the program:
-
node, mesh, grid,
-
size, option, finite element,
-
fields, assembled matrices.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
5/16
2
General architecture of routines FORTRAN
Schematically, the organization of routines FORTRAN is as follows:
program stake
Supervisor
order 1
CALCUL
Aster
order 2
JEVEUX
order 3
…
order N
CALCUL
elementary calculation 1
elementary calculation 2
elementary calculation 3
…
elementary calculation p
Note:
To the 01/10/94:
a number of commands: N = 128
a number of elementary calculations: p = 3043
Superviseur (as routine CALCUL) structure the code because they affirm an independence
between the routines which they call:
routine
0P0001
--> command 1
routine
0P0002
--> command 2
…
…
routine
TE0001
--> elementary calculation 1
routine
TE0002
--> elementary calculation 2
…
…
· the link between a command user and number I of the OP000i routine which corresponds to him
is given in the catalog associated with this command [§ 3.1],
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
6/16
· the link between an elementary calculation (for example: the calculation of geometrical rigidity for one
element of hull of the type DKT) and the routine TE00031 which corresponds to him is given in
catalog associated with this finite element [§ 3.2].
Independence between the OP000i routines is very interesting. It wants to say that to include/understand
the programming of command one does not need to include/understand the others; the only links enters
the commands are the structures of Données which they exchange [§ 5.2]. Those are described
in [D4].
The independence of the TE000i routines is more natural (one will see however that the same routine
TE000i can be associated several close elementary calculations).
Of course, the preceding diagram does not want to say only all source FORTRAN corresponding to
order I is in the OP000i routine: the programmer of a command (like that of one
elementary calculation) can structure its command as it hears it: it can “cut out it” in several
routines.
Schematically, one can write:
OP000i
-->
CALCUL, JEVEUX or any other utility which can be used for
several different commands.
-->
routines specific to the command 0P000i (cutting
functional of OP000i)
The orsque one one seeks the source code associated with a given functionality, one must thus be posed them
following questions:
· is it about a functionality specific to a command?
1) not: to see the utilities common to several commands [D7.01],
· is it about a functionality specific to an elementary calculation?
2) not: to see the utilities common to several elementary calculations [D7.02].
3
Structure of the catalogs
We distinguish two kinds of catalogs:
· catalogs of commands which parameterize the supervisor,
· catalogs of elements which parameterize:
-
routine
CALCUL,
-
commands LIRE_MAILLAGE and AFFE_MODELE.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
7/16
3.1
Catalogs of commands
Architecture is simple: to each ordering of name, commande_i corresponds a catalog of
even name. These catalogs all are independent from/to each other.
catalog
commande_1
catalog
commande_2
…
catalog
commande_n
The contents of the catalog of a command are described in [D5.01.01].
3.2
Catalogs of finite elements
Architecture is still rather simple there. The description of the contents of these catalogs is made in
[D3.02.01].
“cata1 --> cata2” wants to say: the catalog cata1 is pressed on the catalog cata2. In other words, it uses
entities described in the catalog cata2.
Phenomenon/Modeling
type_élément 1
option 1
type_élément 2
option 2
…
…
type_élément Q
option R
types of mesh
sizes
Note:
To the 01/10/94:
numbers type_element: Q = 233
a number of options: R = 159
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
8/16
4
Superviseur of execution
4.1 General
What one calls “Superviseur” is the whole of the routines FORTRAN which belong to
library SUPERVIS.
One can logically cut it into two:
SUP1:
what is used to connect the various commands; i.e. all it
who is (in the tree of call) between the main program and them
OP000i routines (including the main program). One includes in
supervisor contents of 3 particular commands: DEBUT,
POURSUITE and FIN,
SUP2:
what allows the communication of information with OP000i:
routines GETXXX [D6.03.01].
4.2
General operation of Superviseur
1) opening of the 3 data bases JEVEUX [D6.02.01] (makes 3 files of random access of them).
- bases
“LOCALE” it is a base of work reserved for Superviseur, this base is not
backed up at the end of the execution
- bases
“VOLATILE” it is the base reserved for the objects of work (except Superviseur), this
base is not backed up at the end of the execution,
- bases
“GLOBALE” it is the base of the user. It will contain at the end of the execution them
concepts corresponding to the commands carried out
2) reading of the catalogs
-
catalogs of commands
- catalogs
elements
3) reading of the command file of the user
-
reading in free format; elimination of the comments,
-
syntactic checks (using the catalogs of commands),
-
orthography of the key words,
-
types of the arguments,
-
exclusion of the key words,…
-
assignment of the default values,
-
creation of the concepts corresponding to values (DEFI_VALEUR [U4.21.10]) and to
interpreted functions (FORMULE [U4.21.11]),
-
evaluation of the numerical expressions (key word EVAL [U4.21.11 §4.1]),
-
information storage of the command file in objects JEVEUX (bases
local).
4) request for execution of the commands of the user [§ 4.3],
5) impression of the execution time of each command,
6) validation (progressively) of the concepts created by the commands: this allows
“to take again” a calculation which badly finished,
7) closing of the data bases at the end of the execution,
8) program stop.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
9/16
4.3
Ask execution of the commands
Superviseur “loops” twice on the commands read in the command file of
the user:
1ère passes:
phase of additional checks: one checks the data of the user
(what could not be checked by the supervisor),
2nd master key:
production run: truly the command is carried out.
If the user asked:
BEGINNING (PAR_LOT: “OUI”,…)
(it is the default value)
Superviseur carries out the 1ère places on all the orders before starting 2nd
pass. This makes it possible to check all the command file before starting
execution.
If not: BEGINNING (PAR_LOT: “NON”,…)
Superviseur carries out the 2 master keys one after the other for each command.
Note:
Superviseur connects the commands the ones after the others. “Sentences of
language " (commands) are followed without instructions of control: IF THEN ELSE, loops
C,…
4.4 Commands
“Supervisory”
Note:
This paragraph can be jumped in first reading.
The preceding paragraph [§4.3] related to the execution of the “ordinary” commands.
The ordinary commands are those whose number lies between 1 and 9998.
The commands which are not ordinary are:
· commands DEBUT and POURSUITE which do not have an external catalog,
· command FIN associated with the number 9999 which is charged (inter alia things) with
to discharge the memory and to close the data bases,
· commands known as “supervisor”.
The Superviseur commands have a catalog (like the ordinary commands), but their number
is a negative number (key word NUMERO_SUPERVIS__ instead of NUMERO__). Routines FORTRAN
associated name OPS00i.
There are today (01/10/94) 7 Superviseur commands.
The difference in behavior between a Superviseur command and an ordinary command is
that the supervisor carries out a preliminary master key on the Superviseur commands. The idea being
that after this preliminary master key, all occurs as if the command file only contained
ordinary commands. This preliminary master key can be regarded as preprocessing of
command file. The “echo” of the command file (which one finds in file MESSAGE)
represent the state of the command file after this preliminary phase.
The 7 current Superviseur commands break up into two: those which are destroyed at the end
preliminary master key: INCLUDE, PROC, RETURN and MACRO_MATR_ASSE and those which are not
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
10/16
destroyed: DEFI_VALEUR, FORMULE and DETRUIRE. For these 3 last, one will thus pass three times
in the associated OPS00i routine: pass preliminary, passes from additional checks and
pass from execution.
Principal interest of the Superviseur commands (in addition to to have allowed the “include”, the use of the functions
interpreted and of the named constants) is to allow the development of “macro” commands
; MACRO_MATR_ASSE is an example. At the time of the preliminary master key, the command
MACRO_MATR_ASSE dynamically generates the text of several ordinary commands then it
is destroyed. The development of such macro-commands is documented in [D5.01.02].
That is to say the command file:
C_O1
C_S1
C_O2
C_S2
C_O3
where:
C_Oi
are ordinary commands
C_Si
are Superviseur commands
C_S1
is a Superviseur command of the macro type orders which generates them
ordinary commands C_O4 and C_O5.
C_S1 is destroyed at the end of the preliminary master key
C_S2
is a Superviseur command which is not destroyed
· Sequence of the master keys if DEBUT (PAR_LOT: “yes”)
-
place preliminary (for the orders supervisor only): (p)
-
C_S1
p
-
C_S2
p
-
pass from additional checks: (statement)
-
C_O1
statement
-
C_O4
statement
-
C_O5
statement
-
C_O2
statement
-
C_S2
statement
-
C_O3
statement
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
11/16
-
pass from execution: (EP)
-
C_O1
EP
-
C_O4
EP
-
C_O5
EP
-
C_O2
EP
-
C_S2
EP
-
C_O3
EP
· Sequence of the master keys if DEBUT (PAR_LOT: “NON”)
-
C_O1
statement
-
C_O1
EP
-
C_S1
p
-
C_O4
statement
-
C_O4
EP
-
C_O5
statement
-
C_O5
EP
-
C_O2
statement
-
C_O2
EP
-
C_S2
p
-
C_S2
statement
-
C_S2
EP
-
C_O3
statement
-
C_O3
EP
5
JEVEUX and Structuration of Données
We in this paragraph will try to release the principal functionalities of the manager of
memory JEVEUX and of the use that one makes some in Aster.
5.1
Administrative JEVEUX of objects
JEVEUX is the whole of routines FORTRAN described in [D6.02.01].
These routines allow:
· to create objects,
· to save (writing on disc),
· to destroy,
· to release (main memory),
· to recall (in main memory),
· to copy, print them,…
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
12/16
5.1.1 What an object JEVEUX?
· A whole of homogeneous information (entireties, realities, complexes,…),
· each object is named (24 characters),
· each object with accessible attributes in reading (and sometimes in writing):
-
length (for 1 vector),
-
type of the values: entirety, reality,…
-…
· each object has a “image disc virtually”,
· there are simple objects (roughly speaking, they are vectors),
· there are collections of objects,
-
the objects of a collection are all of the same type (but it can have lengths
different),
-
the access of an object of collection is done by the name of the collection plus something which
identify the object:
-
a number (numbered collection),
-
or a name (named collection).
5.1.2 Allowance
dynamics
One can create, at any moment to release (and destroy) an object JEVEUX. That makes it possible to manage
dynamically memory.
Of course, this possibility is used to allocate working areas. It is the only mechanism
of dynamic allocation authorized in Aster because it manages the whole of the place memory available:
(one understands by memory available the place available in the “Région” requested from the execution
less the volume of the executable code minus the zones managed by system UNICOS).
5.1.3 Memory
virtual
When an object A is released, JEVEUX regards it as “déchargeable” (on disc). If news
requests are made on other objects and that the place in main memory has suddenly missed, object A
will be written on disc and its place will be recovered.
JEVEUX thus makes it possible to reach (at different moments) more memory than does not contain any
really the “Région” of main memory allocated with the execution.
It thus acts like a system of “virtual memory”.
5.1.4 Writing and reading on disc
· When one saves explicitly an object (routine JESAUV), this one is written on disc,
· when the execution of Aster finishes, all the objects of the base are automatically saved
total which was not it yet,
· when one points out an object in main memory (routine JEVEUO), this one is read on
disc if it were discharged and recopied in main memory.
JEVEUX thus makes it possible to be freed from all the binary readings and writings on disc.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
13/16
5.2
Structuring of Données
The commands of Aster exchange objects named by the user (8 characters) that one
call concepts.
Example:
steel = DEFI_MATERIAU (ELAS: (E: 300.000 NAKED: 0.3));
chmat = AFFE_MATERIAU (MATER: steel…);
The concept “steel” created by command DEFI_MATERIAU is an argument of input of
order AFFE_MATERIAU.
A concept in fact Structure de Données is named (SD in language programmer).
A structure of data is anything else only one whole of objects JEVEUX.
One can then “handle” in FORTRAN of the structures of data complex: the passage of
SD in argument is done by its name (character string).
This largely improves the definition of the interfaces of the routines: instead of transmitting
multitudes of vectors in arguments, one transmits some structures of data.
The regrouping of a whole of objects JEVEUX in a structure of data is done by
simple known conventions of names of the whole of the programmers.
Structure de Données is typified. When one carries out (for example) the command:
= LIRE_MAILLAGE netted ();
this one must create a SD of the type grid and of name “netted”. At the end of the execution of
order, it must exist on basis “GLOBALE” certain numbers of objects JEVEUX of which
the unit forms the SD netted:
“MAILLA .DIME”
“MAILLA .CONNEX”
“MAILLA .NOMNOE”
“MAILLA .NOMMAI”
…
The first 8 characters of the objects are those coming from the user. The other characters (which
the objects from/to each other are used to distinguish) are fixed by the programmers. The description of
contained objects .DIME, .CONNEX,… form what one calls the description of the SD of the type
grid (cf [D4]).
Important remark:
Only information necessary to the good unfolding of a command is:
· values that the user provided behind the key words of the command:
entireties, realities,…
· SD (already created by preceding commands) given in argument.
There is no information under-terraine (COMMONS, files,…) between the commands. It is the respect
of this rule which ensures the real independence of the commands between them.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
14/16
The only exceptions to this rule are:
· the SD catalogs [D4.01.01] which is accessible everywhere (but it is never modified),
· certain writings (or readings) in files. In this case, the name of the command is
always of the form: IMPR_XXX or (LIRE_XXX).
The “format” of the file can then be seen like the description of a SD, for example:
- grid
Aster (LIRE_MAILLAGE),
- function
Aster (LIRE_FONCTION),
-
results to visualize by I-DEAS (IMPR_RESU (FORMAT: IDEAS…)).
6 Calculations
elementary
We saw with [§2] that various elementary calculations were numerous in Aster.
This significant number of elementary types of calculations results:
· great number of finite elements in the computer codes of structures:
-
isoparametric 2D in Thermique, Mécanique and Acoustique,
-
isoparametric 3D in Thermique, Mécanique and Acoustique,
-
elements of structures: beams, hulls,…
- elements
incompressible,
-
elements of fluid interaction/structure,
-…
· and of the great number of options of possible calculation:
-
mechanical or thermal rigidity,
- mass,
damping,
-
geometrical rigidity or centrifuges,
-
constraints, deformations, flow,
-
surface, voluminal or linear forces,
-
change of gravity, thermal dilation,…
In Aster today (01/10/94), one a:
· 233 types of finite elements (approximately 19000 lines of catalogs),
· 159 options of elementary calculation,
what involves more than 3200 theoretically possible elementary calculations (undoubtedly much
more). Only 3043 of these elementary calculations are actually programmed (approximately 70000 lines
of FORTRAN).
These 3043 elementary calculations are made in 310 TE000i routines; indeed, several calculations
elementary can be implemented in only one TE000i. For example, it is rather easy of
to parameterize the programming of all the isoparametric elements 2D.
The large volume of the code concerned with elementary calculations justifies an effort of
parameterization of these calculations. The objectives of this parameterization are:
· to simplify to the maximum the programming of TE000i: data of an elementary calculation
“arrive” in the routine in the form wanted by the programmer (and described in
catalog element [D3.02.01 §7]),
· to have a single routine (CALCUL) managing all elementary calculations: constraints,
rigidity, thermal “mass”,…. What avoids multiplying the “loops” on the elements, them
controls and error messages: “function” CALCUL accounts for 3500 nevertheless
lines…
· to impose types of Structures de Données commun runs on all the results of calculations
elementary: the CHAM_ELEM (fields by elements) and the RESU_ELEM (matrices and
elementary vectors).
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
15/16
The assembly of the matrices and the elementary vectors can then be made in two
routines (ASMATR and ASSVEC).
The mechanisms of this parameterization are explained in [D3.02.01].
The documents [D5.04.01] and [D5.04.02] describe the manner of introducing new calculations
elementary.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A

Code_Aster ®
Version
3.0
Titrate:
General architecture of Code_Aster
Date:
28/04/98
Author (S):
J. PELLET
Key:
D0.03.01-A
Page:
16/16
Intentionally white left page.
Handbook of Descriptif Informatique
D0.03 booklet: Structure
HI-75/95/007 Ind A