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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
Organization (S):
EDF/IMA/MN
Data-processing manual of Description
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.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
Contents
1 Introduction ...................................................................................................................................... 3
2 general Architecture of routines FORTRAN ................................................................................. 5
3 Architecture of the catalogs ............................................................................................................. 6
3.1 Catalogs of controls ....................................................................................................... 7
3.2 Catalogs of finite elements ....................................................................................................... 7
4 the Supervisor of execution .............................................................................................................. 8
4.1 General information ................................................................................................................................ 8
4.2 General operation of the Supervisor ................................................................................... 8
4.3 Ask execution of the controls ..................................................................................... 9
4.4 Controls “Supervisor” .................................................................................................... …. 9
5 JEVEUX and Structuring of the Data .......................................................................................... 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 the Data ...................................................................................................... 13
6 elementary Calculations ..................................................................................................................... 14
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
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 controls 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,…
The routines CAL were written to optimize performances (CPU) of the method of resolution
linear systems by Combined Gradient.
If the few functions C and the routines CAL are forgotten, we see that the program
Aster 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 shaft of complete call of the program
Code_Aster was written
on more than 6.10
8
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 Project (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 controls that the user
connect with its liking,
2) these controls 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.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
They are these three ideas that we will develop in the following paragraphs:
1) is identified about so that one calls the Supervisor of execution
[
§4],
2) is possible thanks to the manager of memory JEVEUX and the Structuring of the Data
[§5],
3) corresponds to the parameterization of elementary calculations and the existence of the routine
CALCULATION [§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 “locking plate” 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, mesh,
-
size, option, finite element,
-
fields, assembled matrices.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
2
General architecture of routines FORTRAN
Schematically, the organization of routines FORTRAN is as follows:
program stake
Aster
Supervisor
order 1
order 2
order 3
…
order
N
CALCULATION
JEVEUX
CALCULATION
elementary calculation 1
elementary calculation 2
elementary calculation 3
elementary calculation
p
…
elementary calculation 3
Note:
To the 01/10/94:
a number of controls: N = 128
a number of elementary calculations: p = 3043
The Supervisor (as the routine CALCULATION) structure the code because they affirm an independence
between the routines which they call:
routine
0P0001
--> control 1
routine
0P0002
--> control 2
…
…
routine
TE0001
--> elementary calculation 1
routine
TE0002
--> elementary calculation 2
…
…
·
the link between a control user and number I of the OP000i routine which corresponds to him
is given in the catalog associated with this control [§ 3.1],
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
·
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
who corresponds to him is given in
catalog associated with this finite element [§ 3.2].
Independence enters the routines
OP000i
is very interesting. It wants to say that to include/understand
the programming of control one does not need to include/understand the others; the only links enters
the controls are the structures of Data 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 control (like that of one
elementary calculation) can structure its control as it hears it: it can “cut out it” in several
routines.
Schematically, one can write:
OP000i
-->
CALCULATION
,
JEVEUX
or any other utility which can be used for
several different controls.
-->
routines specific to the control
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 control?
1) not: to see the utilities common to several controls [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 controls which parameterize the supervisor,
·
catalogs of elements which parameterize:
-
routine
CALCULATION
,
-
controls LIRE_MAILLAGE and AFFE_MODELE.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
3.1
Catalogs of controls
Architecture is simple: with each ordering of name,
commande_i
a catalog corresponds 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 control 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
types of mesh
type_élément 2
…
type_élément 1
type_élément Q
option 1
option 2
option R
type_élément 2
…
…
sizes
Note:
To the 01/10/94:
numbers type_element: Q = 233
a number of options: R = 159
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
4
The Supervisor of execution
4.1 General
What one calls “Supervisor” 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 controls; i.e. all it
who is (in the shaft of call) between the main program and them
routines
OP000i
(including the main program). One includes in
supervisor contents of 3 particular controls:
BEGINNING
,
CONTINUATION
and
END
,
SUP2:
what allows the communication of information with
OP000i
:
routines
GETXXX
[D6.03.01].
4.2
General operation of the Supervisor
1) opening of the 3 data bases
JEVEUX
[D6.02.01] (makes 3 files of random access of them).
- bases
“
LOCAL
“it is a base of work reserved to the Supervisor, this base is not
backed up at the end of the execution
- bases
“
BIRD
“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
“
TOTAL
“it is the base of the user. It will contain at the end of the execution them
concepts corresponding to the controls carried out
2) reading of the catalogs
-
catalogs of controls
- 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 controls),
-
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 the values (
DEFI_VALEUR
[U4.21.10]) and with
interpreted functions (
FORMULATE
[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 controls of the user [§ 4.3],
5) impression of the execution time of each control,
6) validation (progressively) of the concepts created by the controls: 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.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
4.3
Ask execution of the controls
The Supervisor “loops” twice on the controls read in the command file of
the user:
1
era
pass:
phase of additional checks: one checks the data of the user
(what could not be checked by the supervisor),
2
ème
pass:
production run: truly the control is carried out.
If the user asked:
BEGINNING (PAR_LOT: “YES”,…)
(it is the default value)
the Supervisor carries out the 1
era
place on all the orders before beginning the 2
ème
pass. This makes it possible to check all the command file before starting
execution.
If not:
BEGINNING (PAR_LOT: “NOT”,…)
The Supervisor carries out the 2 master keys one after the other for each control.
Note:
The Supervisor connects the controls the ones after the others. “Sentences of
language " (controls) are followed without instructions of control: IF THEN ELSE, loops
C,…
4.4 Controls
“Supervisory”
Note:
This paragraph can be jumped in first reading.
The preceding paragraph [§4.3] related to the execution of the “ordinary” controls.
The ordinary controls are those whose number lies between 1 and 9998.
The controls which are not ordinary are:
·
controls
BEGINNING
and
CONTINUATION
who do not have an external catalog,
·
the control
END
associated the number 9999 which is charged (inter alia things) with
to discharge the memory and to close the data bases,
·
controls known as “supervisor”.
The Superviseur controls have a catalog (like the ordinary controls), but their number
is a negative number (key word
NUMERO_SUPERVIS__
instead of
NUMERO__
). Routines FORTRAN
associated name themselves
OPS00i
.
There are today (01/10/94) 7 Superviseur controls.
The difference in behavior between a control Supervisor and an ordinary control is
that the supervisor carries out a preliminary master key on the Superviseur controls. The idea being
that after this preliminary master key, all occurs as if the command file only contained
ordinary controls. This preliminary master key can be regarded as preprocessing of
command file. The “echo” of the command file (which one finds in the file
MESSAGE
)
represent the state of the command file after this preliminary phase.
The 7 current Superviseur controls 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
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
destroyed:
DEFI_VALEUR
,
FORMULATE
and
TO DESTROY
. For these 3 last, one will thus pass three times
in the routine
OPS00i
associated: pass preliminary, passes from additional checks and
pass from execution.
Main interest of the controls Supervisor (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” controls
;
MACRO_MATR_ASSE
in is an example. At the time of the preliminary master key, the control
MACRO_MATR_ASSE
dynamically generate the text of several ordinary controls then it
is destroyed. The development of such macro-controls 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 controls
C_Si
are Superviseur controls
C_S1
is a Superviseur control of the macro type orders which generates them
ordinary controls
C_O4
and
C_O5
.
C_S1
destroys itself at the end of the preliminary master key
C_S2
is a Superviseur control which is not destroyed
·
Sequence of the master keys if
BEGINNING
(
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
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
-
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
BEGINNING
(
PAR_LOT: “NOT”
)
-
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 Structuring of the Data
We in this paragraph will try to release the main functionalities of the manager of
memory
JEVEUX
and of the use that one makes some in
Aster.
5.1
JEVEUX
manager 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,…
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
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 “Area” requested from the execution
less the volume of the executable code minus the areas managed by system UNICOS).
5.1.3 Memory
virtual
When an object is released
With
,
JEVEUX
regards 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 allows to reach (at different moments) more memory than does not contain any
really the “Area” 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 an object (routine explicitly
JESAUV
), the aforementioned is written on disc,
·
when execution of
Aster finishes, one automatically saves all the objects of the base
total which was not it yet,
·
when one points out an object in main memory (routine
JEVEUO
), the aforementioned 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.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
5.2
Structuring of the Data
Controls 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 the control
DEFI_MATERIAU
is an argument of input of
order
AFFE_MATERIAU
.
A concept is in fact a named Structure of Data (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.
A Structure of Data is typified. When one carries out (for example) the control:
= LIRE_MAILLAGE netted ();
the aforementioned must create a SD of the type
mesh
and of name “
netted
“. At the end of the execution of
order, it must exist on the basis
“TOTAL”
certain numbers of objects
JEVEUX
of which
the unit forms the SD
netted
:
'NETTED
.DIME'
'NETTED
.CONNEX'
'NETTED
.NOMNOE'
'NETTED
.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
contents of the objects.
DIME
.
CONNEX
,… form what one calls the description of the SD of the type
mesh
(cf [D4]).
Important remark:
Only information necessary to the good unfolding of a control is:
·
values that the user provided behind the key words of the control:
entireties, realities,…
·
SD (already created by preceding controls) given in argument.
There is no information under-terraine (
COMMONS
, files,…) between the controls. It is the respect
of this rule which ensures the real independence of the controls between them.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
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 control 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:
- mesh
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 Thermics, Mechanics and Accoustics,
-
isoparametric 3D in Thermics, Mechanics and Accoustics,
-
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,
-
stresses, 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 routines
TE000i
; 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 (
CALCULATION
) managing all elementary calculations: stresses,
rigidity, thermal “mass”,…. What avoids multiplying the “loops” on the elements, them
controls and error messages: the “function”
CALCULATION
account for 3500 nevertheless
lines…
·
to impose types of Structures of Data commun runs on all the results of calculations
elementary:
CHAM_ELEM
(fields by elements) and them
RESU_ELEM
(matrices and
elementary vectors).
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
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.
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
Data-processing manual of Description
D0.03 booklet: Structure
HI-75/95/007 Ind A
Intentionally white left page.