Introduction
============

The Code_Aster consists of various "modules" that can be classified into:


* main program FORTRAN 77,


* routines FORTRAN 77 (subroutine or function),


* C functions,


* routines CAL (CRAY assembling language),


* catalogs.

All the texts in these modules are the source of Aster (around 400,000 lines). Catalogs are text files that configure certain programs: mainly the command analyzer and the elementary calculations (in the sense of the finite element method).

C functions perform certain "system" tasks that are impossible in FORTRAN 77: dynamic allocation, time measurement,...

Routines CAL were written to optimize the performance (CPU) of the method for solving linear systems by Conjugate Gradient.

If we forget the few C functions and the CAL routines, we see that the Aster program consists of:


* a few hundred catalogs,


* a few thousand FORTRAN 77 routines.

The purpose of this document is to help "find yourself" in this large number of modules: for FORTRAN alone, we calculated that the complete call tree of the Code_Aster program was written on more than 6,108 lines, which excludes giving it as an appendix!

Under these conditions, how to identify the sources relating to a given functionality? Where do I insert a new feature?

One form of answer to these 2 questions is in the general architecture of the code that was chosen at the beginning of the Project (07/89) and which has not been questioned since then.

This architecture can be summed up in roughly three ideas:


1. Code_Aster can be seen as a set of independent commands that the user strings together at will,


2. these commands exchange named objects ("concepts") which are themselves made up of objects JEVEUX,


3. Since Code_Aster is a finite element code, the concept of "elementary" calculation (i.e. performed by a finite element) is strictly codified because it constitutes in a way the "core" of the numerical method.

*Note:*

*The first 2 ideas are* **very general and could be used as an architecture for many software programs outside the field of finite elements.*

These are the three ideas that we will develop in the following paragraphs:


1. is roughly identified with what is called the Execution Supervisor (see § :ref:`4 <RefHeading__29121712>` The Execution Supervisor),


2. is possible thanks to the memory manager JEVEUXet to Data Structuring (see § :ref:`5 <RefHeading__29123101>` JEVEUXet Data Structuring),


3. corresponds to the parametrization of elementary calculations and to the existence of routine CALCUL (see § :ref:`6 <RefHeading__29123553>` Elementary calculations).

*Notes:*

*Idea 2 does not structure the code itself, but it makes it possible to achieve 1,*

*while these three ideas strongly structure the code, they also form the "straitjacket" of programming: there is no getting away from them. The rest of the programming is fairly free,*

*the implementation of idea 3, in addition to the fact that it structures a large volume of code (19000 lines of catalogs and 70,000 lines of* FORTRAN *), freezes a certain number of essential concepts of the program:*

 *→ knot, mesh, mesh,*

 *→ size, option, finite element,*

 *→ fields, assembled matrices.*


.. _RefHeading__29213459: