1. Introduction#

Le Code_Aster est constitué de différents “modules” que l’on peut classer en :

  • programme principal FORTRAN 77,

  • routines FORTRAN 77(subroutineou function),

  • fonctions C,

  • routines CAL (CRAY assembling language),

  • catalogues.

L’ensemble des textes de ces modules constitue le source d’Aster (environ 400 000 lignes). Les catalogues sont des fichiers textes qui paramètrent certains programmes : principalement l’analyseur de commandes et les calculs élémentaires (au sens de la méthode des éléments finis).

Les fonctions C réalisent certaines tâches “système” impossibles en FORTRAN 77 : allocation dynamique, mesure de temps, …

Les routines CAL ont été écrites pour optimiser les performances (CPU) de la méthode de résolution des systèmes linéaires par Gradient Conjugué.

Si l’on oublie les quelques fonctions C et les routines CAL, nous voyons que le programme Aster est constitué de :

  • quelques centaines de catalogues,

  • quelques milliers de routines FORTRAN 77.

Le but de ce document est d’aider à se “retrouver” dans ce grand nombre de modules : rien que pour le FORTRAN, nous avons calculé que l’arbre d’appel complet du programme Code_Aster s’écrivait sur plus de 6.108 lignes, ce qui exclut de le donner en annexe !

Comment, dans ces conditions, identifier les sources relatifs à une fonctionnalité donnée ? Où insérer une nouvelle fonctionnalité ?

Une forme de réponse à ces 2 questions est dans l’architecture générale du code qui a été choisie au début de Projet (07/89) et qui n’a pas été remise en cause depuis.

Cette architecture peut se résumer à peu près en trois idées :

  1. Code_Aster peut être vu comme un ensemble de commandes indépendantes que l’utilisateur enchaîne à son gré,

  2. ces commandes s’échangent des objets nommés (“concepts”) qui sont eux mêmes constitués d’objets JEVEUX,

  3. Code_Aster étant un code d’éléments finis, la notion de calcul “élémentaire” (i.e. fait par un élément fini) est strictement codifiée car elle constitue en quelque sorte le “noyau” de la méthode numérique.

Remarque :

Les 2 premières idées sont **très généraleset pourraient servir d’architecture à de nombreux logiciels hors du domaine des éléments finis.*

Ce sont ces trois idées que nous allons développer dans les paragraphes suivants :

  1. s’identifie à peu près à ce que l’on appelle le Superviseurd’exécution (voir le § 4 Le Superviseur d’exécution),

  2. est possible grâce au gestionnaire de mémoire JEVEUXet à la Structurationdes Données(voir le § 5 JEVEUXet Structuration des Données),

  3. correspond à la paramétrisation des calculs élémentaires et à l’existence de la routine CALCUL(voir le § 6 Calculs élémentaires).

Remarques :

L’idée 2 ne structure pas le code à proprement parler, mais elle permet de réaliser 1,

si ces trois idées structurent fortement le code, elles forment également le “carcan” de la programmation : on ne peut s’y soustraire. Le reste de la programmation est assez libre,

la mise en œuvre de l’idée 3, outre le fait qu’elle structure un volume important de code (19000 lignes de catalogues et 70000 lignes de FORTRAN ), fige un certain nombre de notions essentielles du programme :

→ nœud, maille, maillage,

→ grandeur, option, élément fini,

→ champs, matrices assemblées.