9. Outils de vérification et de restitution#

Ils sont situés dans le répertoire /aster/astest/vers où vers désigne la version associée et sont également disponible via l’environnement d’utilisation asterix [§12 D1.02.01].

9.1. aslien : délégation du droit de restitution#

Lorsque des développements sont dépendants il faut pouvoir les rendre simultanément afin de tester le code. Cela oblige un des développeurs à centraliser les développements et à effectuer la restitution pour les autres développeurs.

Pour éviter les problèmes, les développeurs doivent déléguer leurs droits de restitution à celui qui centralise les développements.

Cette délégation est exclusive pour une seule version et valable jusqu’à la mise à jour de la nouvelle version. La délégation peut cependant être rendue par le bénéficiaire, ou par l’administrateur.

Un développeur ne peut déléguer qu’une seule fois ce droit (pour une version donnée). Le bénéficiaire d’une délégation ne peut pas déléguer lui même son droit de restituer.

9.1.1. Mode d’appel#


aslien user_beneficiaire[version[message]]

user_beneficiaire : user Cray du développeur bénéficiant de la délégation de restitution.

version : est un paramètre qui porte le nom de la version de référence concernée (NEW1, NEW2, NEW3). Par défaut actuellement: NEW3.

message : définition identique à asno. Par défaut: message_aslien.

9.1.2. Tâches réalisées#

Vérifier que le user_beneficiaire existe dans ident et est différent de l’appelant ( iret = 4).

Vérifier que l’appelant n’a pas déjà délégué son droit de restitution ( iret = 4).

Vérifier que le user_beneficiaire n’a pas déjà délégué son droit de restitution ( iret =4).

Vérifier que l’appelant n’est pas déjà bénéficiaire de droits de restitution ( iret =4).

Si iret < 4 compléter le fichier lien_dvp avec:

  • user de l’appelant,

  • user_beneficiaire,

  • version,

  • jj/mm/aa date d’utilisation de aslien,

  • (nom_developpeur_appelant -> nom_developpeur_beneficiaire) déterminés à partir du fichier ident.

9.2. aslibe : libération du droit de restitution#

Libération de la délégation de restitution par le bénéficiaire ou l’administrateur.

9.2.1. Mode d’appel#


aslibe user[version[message]]

user : user Cray du développeur qui a délégué son droit de restitution.

version : est un paramètre qui porte le nom de la version de référence concernée (NEW1, NEW2, NEW3). Par défaut actuellement: NEW3.

message : définition identique à asno. Par défaut: message_aslibe.

9.2.2. Tâches réalisées#

Vérifier que l’appelant et user sont différents et définis dans ident( iret =4).

Si l’appelant est l’administrateur alors suppression de la ligne de lien_dvp contenant en premier champ user pour la version version (si elle n’existe pas iret = 4).

Si l’appelant est un développeur alors suppression de la ligne de lien_dvp contenant en premier champ user et en deuxième champ le user de l’appelant pour la version version (si elle n’existe pas iret = 4).

9.3. asquil : liste des délégations de restitution#

Liste dans le fichier de message d’asquil de toutes les délégations de restitution accordées.

9.3.1. Mode d’appel#


asquil [message]

message : définition identique à asno. Par défaut: message_asquil.

9.3.2. Tâches réalisées#

Recopier le fichier lien_dvp dans message .

9.4. asverif : vérification de source#

Vérifier qu’un ensemble de source peut être introduit dans une version de référence du Code Aster .

Cet outil effectue une partie des tâches réalisées par le module de restitution de source asrest qui, devra, être utilisé obligatoirement par toute personne souhaitant effectivement restituer un développement.

asverif permet de vérifier une restitution groupée, dans le cas où les restitutions de plusieurs développeurs sont dépendantes.

asverif travaille dans un répertoire temporaire.

9.4.1. Mode d’appel#


asverif repertoire[version [ message ]]

repertoire est le nom d’un répertoire qui contient un répertoire par développeur désirant restituer du source. Les noms de ces répertoires doivent être le user-Cray du développeur pour déterminer l’auteur du source restitué. Dans chacun de ces répertoires on peut trouver, suivant les cas, les fichiers:

repertoire/user(s)/


histor

dans lequel on trouve un descriptif des évolutions apportées (obligatoire).

fortran

dans lequel se trouve du source FORTRAN.

cal

dans lequel se trouve du source assembleur.

catalogu

dans lequel se trouve des éléments de catalogues.

unigest

dans lequel on indique les unités de source que l’on souhaite déplacer d’une bibliothèque à une autre ou supprimer.

test/

répertoire dans lequel se trouvent des fichiers de commande de cas-tests *.commet éventuellement, des fichiers *.mailou *.para


c/

répertoire dans lequel se trouvent des fichiers des fonctions C *.c.

message : définition identique à asno. Par défaut: message_asverif.

version est un paramètre qui porte le nom de la version de référence concernée (NEW1, NEW2, NEW3). Par défaut actuellement: NEW3.

9.4.2. Tâches réalisées#

Les tâches décrites ci-dessous le sont pour tous les fichiers des répertoires user(s) contenus dans repertoire . Ces répertoires ont le nom d’un user Cray contenu dans le fichier ident et pour lequel l’appelant détient une délégation de restitution (fichier lien_dvp).

Seul(s) le(s) fichier(s) histor est(sont) obligatoire(s), les actions décrites ci-dessous ne sont, bien entendu, réalisées que si les fichiers auxquels elles font référence existent. Dans certain cas, des actions de substitution seront effectuées, elles seront clairement spécifiées.

  • Destruction de tous les répertoires et de tous les fichiers se trouvant dans le(s) répertoire(s) « $TMPDIR/ user(s) « . Recopie du contenu des repertoire / user(s) dans les répertoires « $TMPDIR/ user(s) « .

Le module travaille alors à partir des fichiers qui se trouvent dans $TMPDIR/user(s).

Les répertoires $TMPDIR/user(s) » sont protégés en écriture à tout utilisateur sauf à l’utilisateur administrateur . asverif (qui a les priorités de l’administrateur) travaille alors uniquement dans les fichiers de $TMPDIR/ser(s).

  • Vérification du type des fichiers fortran, catalogu, unigest, test/*.comm selon les critères énoncés dans la tâche 1 de asno.

Vérification que histor est non vide (pour chaque user ).

  • Vérifications d’ordre syntaxique

  • Pour fortran et histor:

Détection des lignes de plus de 72 caractères et inscription des lignes correspondantes dans message ( iret = 4).

Détection des lignes et inscription des lignes correspondantes dans message ( iret =2) contenant:

des caractères minuscules,

des caractères autres que l’alphabet A-Z, les chiffres 0-9, l’espace, la tabulation et les signes: , ) ( * + - = / “ & § ! %: «  . ? $ < > _

Détection des lignes et inscription des lignes correspondantes dans message ( iret =4) contenant: des caractères autres que l’alphabet A-Z et a-z, les chiffres 0-9, l’espace, la tabulation et les signes: , ) ( * + - = / “ & § ! %: «  . ? $ < > ; é è # [ ]

  • Pour catalogu:

Détection des lignes de plus de 72 caractères et inscription des lignes correspondantes dans message ( iret = 4).

Détection des lignes et inscription des lignes correspondantes dans message ( iret = 4) contenant:

des caractères autres que l’alphabet A-Z, les chiffres 0-9 et les signes:

, ) ( * + - = / “ & § ! % ; é è à _

  • Pour unigest:

Détection des lignes de plus de 72 caractères et inscription des lignes correspondantes dans message ( iret = 4).

Vérification que chaque unité n’est référencée qu’une seule fois sur l’ensemble des développeurs.

  • Pour test/*.comm:

Détection des lignes de plus de 72 caractères et inscription des lignes correspondantes dans message ( iret = 4).

Détection des lignes et inscription des lignes correspondantes dans message ( iret =4) contenant:

des caractères autres que l’alphabet A-Z et a-z, les chiffres 0-9 et les signes:

, ) ( * + - = / “ & § ! % ; é è à _

  • Pour histor:

Détection des lignes de plus de 72 caractères et inscription des lignes correspondantes dans message ( iret = 4).

Détection des lignes contenant un caractère autre que: tout caractère autorisé dans les différents types de source sauf les caractères accentués et inscription des lignes correspondantes dans message ( iret = 4).

  • Recherche du nom des unités de source selon les critères énoncés pour la tâche B d’asno.

  • Recherche dans le fichier de code noté des unités de source déjà notées.

  • Si user n’est pas le seul à avoir noté l’unité de source:

si c’est le premier un message indiquant le nom de l’unité est inscrit dans message ( iret = 0),

sinon un message indiquant le nom de l’unité et le nom de l’auteur premier noté est inscrit dans message ( iret = 4),

Si une unité n’a pas été notée un message indiquant le nom de l’unité est inscrit dans message ( iret = 0) et (très gentiment) on la note.

  • Vérification de cohérence avec la version de référence version :

  • Vérification que les unités de source de fortran ou cal ou c/*.c ou catalogu:

du type MODIF sont restituées dans la bonne bibliothèque et à la même date que la version de référence version .,

du type AJOUT n’existent pas déjà dans toutes les bibliothèques d” Aster et sont restituées dans une bibliothèque existante.

  • Vérification que les bibliothèques spécifiées des unités de source de unigest à détruire sont correctes pour la version version ..

  • Vérification que les bibliothèques spécifiées des unités de source de unigest à déplacer sont correctes pour la version version ..

  • Vérification que les cas-tests:

du type MODIF existent et à la même date que la version de référence version,

du type AJOUT n’existent pas déja

Si tel n’est pas le cas, les unités de source incriminées sont signalées dans le fichier message ( iret = 4).

  • Destruction de tous les répertoires et de tous les fichiers se trouvant dans le répertoire « $TMPDIR/ user(s) « .

9.5. asrest : restitution de source#

Vérifier qu’un ensemble de source peut être introduit dans une version de référence du Code Aster et préparer la mise à jour éventuelle.

Cet outil effectue un certain nombre de vérifications puis il lance le passage des cas-tests de référence dans un job (de nuit par défaut mais modifiable).

Cet outil doit être utilisé par toute personne souhaitant restituer un développement.

Comme asverif, asrest permet d’effectuer une restitution groupée pour les développements dépendants.

9.5.1. Mode d’appel#


asrest repertoire[version [ message [classe_job]]]

repertoire est le nom d’un répertoire. Il a la même fonction que dans asverif. On peut donc y trouver, suivant les cas, dans des répertoires user-CRAY les fichiers:

  • histor,

  • fortran,

  • cal,

  • catalogu,

  • unigest,

  • test/

  • *.comm Fichier de commande du cas-test,

  • *.mail Maillage Aster du cas-test,

  • *.mali Maillage Ali-Baba du cas-test,

  • *.mgib Maillage Gibi du cas-test,

  • *.msup Maillage Super-Tab du cas-test,

  • *.para Paramètres d’exécution du cas-test.

  • c/*.c Fichiers des fonctions C.

Par rapport à asverif on doit trouver dans le répertoire test/ tous les fichiers nouveaux ou modifiés concernant les cas-tests ajoutés ou modifiés.

version : est un paramètre qui porte le nom de la version de référence concernée (NEW1, NEW2, NEW3). La valeur prise par défaut est NEW3.

message : définition identique à asno. La valeur prise par défaut est message_asrest.

classe_job : classe des jobs Cray soumis par as.tout.

9.5.2. Tâches réalisées#

Seul(s) le(s) fichier(s) histor est(sont) obligatoire(s), les actions décrites ci-dessous sont, bien entendu, réalisées que si les fichiers auxquels elles font référence existent. Dans certain cas, des actions de substitution seront effectuées, elles seront clairement spécifiées.

  • Tâches de asverif sauf la destruction des répertoires de travail

  • Si iret ≥ 4 FIN.

  • Enregistrement du répertoire complet de repertoire / user(s) dans le(s) fichier(s) eda/ version / user(s) /identifi

  • Insertion dans user(s)/histor de l’auteur et de la date courante.

  • Mise à jour des dates et des auteurs dans les lignes INFO:

  • les lignes AJOUT sont changées en MODIF,

  • les dates sont mises à la date d’utilisation d’asrest,

  • l’auteur porté par la ligne est mis à user plus le nom du développeur.

Chaque mise à jour fait l’objet d’une inscription dans le fichier de récapitulation eda/version/user/recap

  • Eclatement des routines de user(s) /fortran dans le répertoire eda/ version / user(s) /bibfor/ bibli avec une routine par fichier, bibli étant la bibliothèque spécifiée par la ligne INFO.

Recopie des routines à déplacer de FORDEPLA de l’ancienne bibliothèque de référence dans eda/ version / user /bibfor/ bibli où bibli est la nouvelle bibliothèque.

  • Compilation des routines de eda/ version / user(s) /bibfor, avec:

cft77_aster dvpdbg

les errors de compilation sont recopiées dans message ( iret = 4), les WARNINGS également ( iret = 2).

Le module objet est conservé dans fortran.o .

(Dans le cas de développements dépendants il y a une copie dans chaque eda/ version / user concerné.)

  • Si iret ≥ 4 FIN.

  • segldr avec les bibliothèques objets de la version version. Le module exécutable porte le nom execut.

(Dans le cas de développements dépendants il y a une copie de execut dans chaque eda/ version / user concerné).

  • Compilation des catalogues (tâches définies pour ccat92 moins les vérifications, -qui sont déjà effectuées dans asrest).

  • Si iret ≥ 4 FIN.

  • Recopier dans eda/ version / user(s) la liste des cas-tests a passer (liste_ct.rest) et l’enrichir des cas-tests présents dans cette évolution.

  • Lancement des cas-tests (par défaut en classe nuit).

Tâches identiques à as.tout avec les fichiers crées par asrest (execut, catalogue de commandes et d’éléments s’ils sont présents).

La classe des jobs de cas-test par défaut le batch de nuit (sinon paramètre classe_job ).

Le lancement des cas-tests est interrompu si au moins 5 cas-tests ne se terminent pas par OK.

Pour passer les tests un repertoire eda/ version / user_de_reference /astout est créé. Dans ce repertoire se trouvent tous les fichiers de cas-tests nécessaires. (Ceux qui surchargent la référence). Les résultats des cas-tests non OK seront également dans ce répertoire sous resu_NOOK/ et resu_NOOK/flash. (cf as.tout). Le user_de_reference est le user de l’appelant s’il rend lui même du source, sinon c’est le premier user par ordre alphabétique des développeurs qui restituent.

Les fichiers .code et .resu des cas-test ajoutés sont conservés. Les informations pour la mise à jour de la liste des cas-tests (temps total, mémoire requise) des cas-tests ajoutés ou modifiés sont conservé.

  • Recopie du fichier message dans le(s) fichier(s) eda/ version / user(s) /message.

Recopie de la valeur de iret dans le(s) fichier(s) eda/ version / user(s) /iret.

9.5.3. Fichiers créés#

Les fichiers créés sont:

/aster

/eda/ version

/ user(s)

/histor

/fortran /cal

/catalogu

/test

/ nom_cas_test .comm / nom_cas_test .para / nom_cas_test .mail / nom_cas_test .mali / nom_cas_test .msup / nom_cas_test .mgib

/unigest

/bibfor /bibcal /bibc

/ bibli / bibli / bibli

/ routine.f / module.cal / fonction_C.c

/obj

/fortran.o /cal.o / fonction_C .o

/execut

/catalo

/ bibli

/ subcat.cata

/catobj

/commande

/elements

/identifi

/message

/iret

/recap /ls_ct

/astout

/.comm /.para /.mail /.mali /.msup /.mgib

/liste_ct

/resu_NOOK

/*.resu

/*.code

/flash/*error *output

9.6. as.tout : passage de cas-tests#

Enchaînement d’une liste de cas-tests avec analyse des résultats.

Caractéristiques principales de cet outil:

  • construction des scripts de commandes Unicos de chaque cas-test à partir des fichiers de données Aster ,

  • soumission de ces cas-tests en utilisant la possibilité du Cray d’exécuter plusieurs jobs en même temps,

  • collecte des résultats des différents jobs,

  • réalisation d’un document synthétique de l’ensemble des cas-tests envoyés et éventuellement exécution d’une action en fonction du résultat des cas-tests.

Exemple de synthèse:

-- A S T E R -- VERSION 2.05.11 --

— Fin de tous les cas tests : le 12/07/93 a 15:21:01 — Voici les resultats:

Temps CPU Temps SYS Temps Total Cout

adlv100a OK 5.28 0.92 6.20 13.79 F ahlv100b NOOK_TEST_RESU 6.70 0.65 7.35 16.33 F hplv100a OK 7.80 0.63 8.42 18.72 F hplv101a OK 4.34 0.72 5.05 11.23 F hplv101b CPU_TIME_LIMIT 6.29 0.82 7.11 15.80 F hsnl100a OK 3.04 0.67 3.71 8.24 F hsnv100a OK 10.81 0.69 11.50 25.56 F ——– —- ————— ——– ——– ——– ——– 7 5 2 44.26 5.09 49.35 109.67 F

PROBLEME AVEC 2 CAS-TESTS

as.tout vérifie la cohérence des arguments transmis puis construit et soumet un job (qastout) de la même classe que celle des cas-tests. Ce job construit et soumet des chaînes de cas-tests et attend la fin de tous les cas-tests lancés pour mettre en forme les résultats et les envoyer dans le fichier message.

9.6.1. Mode d’appel#

as.tout fichier_parametre [message]

fichier_parametre : Fichier contenant les différents paramètres d’exécution d’as.tout.

message : fichier des messages. Par défaut message_astout.

fichier_parametre contient 12 valeurs.

Un paramètre est le premier champ d’une ligne ne débutant pas par le caractère ‘%’. Il ne peut donc pas y avoir plusieurs paramètres sur la même ligne.

La reconnaissance des paramètres se fait sur l’ordre de déclaration. Si l’on veut avoir la valeur par défaut d’un paramètre il faut le remplacer par le caractère ‘.’. Les lignes vides sont autorisées.

Les paramètres sont les suivants:

  • nom du fichier contenant la liste des cas-tests (pas de valeur par défaut),

  • répertoire contenant les fichiers référence des cas-tests (fichiers de commandes, de maillages et paramétres avec la même organisation que dans la base de référence par défaut /aster/astest/ version /-),

  • répertoire contenant des fichiers de cas-tests qui surchargeront les fichiers de référence (pas de valeur par défaut),

  • répertoire recevant les résultats (pas de valeur par défaut), les fichiers nom_cas‑test.resu et nom_cas-test.code y sont crées et, s’il n’existe pas déjà, un répertoire flash/ est créé, il reçoit les fichiers nom_cas-test.error et nom_cas‑test.output),

  • nom de l’exécutable Aster (par défaut /aster/ version /execut),

  • fichier contenant le catalogue des commandes compilées (par défaut /aster/ version /catobj/commande ),

  • fichier contenant le catalogue des éléments compilés (par défaut /aster/ version /catobj/elements ),

  • la classe de job Cray pour passer les cas-tests: batch ou nbatch ou wbatch (par défaut nbatch -batch de nuit-),

  • le nombre maximum de cas-tests qui se terminent mal avant interruption du lancement des autres cas-tests (pas de défaut),

  • la version Aster pour les cas-tests (sert à déterminer les noms par défaut, NEW3 par défaut),

  • si “DATE” la date et l’heure est rajoutée en extension des résultats des jobs, sinon les extensions .error et .output sont ajoutées au nom du cas-tests pour le résultat des jobs Cray,

  • si “RESOK” les fichiers de résultat de tous les jobs lancés sont envoyés dans le répertoire résultat ; pour toute autre valeur, seuls les résultats des jobs non OK sont conservés.

9.6.2. Tâches réalisées#

Par as.tout:

  • Vérification des paramètres:

  • Existence des différents répertoires et fichiers.

  • Vérification des domaines de validité des paramètres classe du job, version et datation des fichiers du « flasheur ».

  • Vérification que les noms de cas-test respectent la régle de nommage (des lettres puis des chiffres et une lettre).

  • Si iret ≥ 4 FIN.

  • Vérification de l’existence des fichiers .para des cas-test à passer.

  • Construction du job lanceur de cas-test de même classe que les cas-tests.

  • Soumission de ce job par qastout.

Par le lanceur de cas-test qastout:

  • Vérifications des deux premières tâches de as.tout .

  • Création d’un répertoire dans /tmp pour collecter les résultats de tous les cas-tests.

  • Construction des jobs de tous les cas-tests.

Chaque job vérifie les principes suivants:

  • si les paramètres NQS sont incompatibles avec la machine fin de as.tout (iret=4),

  • si le cas-test n’est pas le dernier d’une chaîne:

  • teste le code retour du qsub du cas-test suivant,

  • vérifier par qstat que le cas-test est bien pris en compte par NQS,

  • envoyer un mail sur Cray à l’administrateur Aster (d6bhhhh) en cas de problème détecté par NQS,

  • en cas de problème NQS appel au script Dernier_Job.

  • si le cas-test est le dernier d’une chaîne:

  • appel au script Dernier_Job.

  • Soumission des cas-tests sous la forme de 16 chaînes séquentielles lancées en parallèle.

Le script Dernier_Job est appelé par tout cas-test détectant un problème NQS et le dernier job de chaque chaîne. Ce script doit déterminer si le job qui l’appelle est le dernier cas-test en exécution sur Cray parmi tous les cas-tests lancés par cet as.tout. Si c’est le cas Dernier_Job invoque le job Dernier_Job.btc

Tâches du job Dernier_Job.btc:

Mise en forme du résultat des cas-tests

Pour chaque cas-test soumis affichage

  • d’un diagnostic:

  • OK,

  • ARRET_ANORMAL (arrêt non géré par Aster ),

  • <F>_SUPERVISEUR ( Aster interrompu par le superviseur),

  • ERREUR_<F> (autres erreurs fatales détectées par Aster ),

  • ERREUR_<S> écrasement ?????? sans conséquence visible,

  • <E>_VOLATILE il reste un objet dans la base volatile,

  • NOOK_TEST_RESU (non respect de la valeur de référence),

  • DEFAUT_FICHIER (il manque un fichier ou un répertoire indispensable au cas-test),

  • CPU_LIMITE (manque de temps pour finir le cas-test),

  • INTERRUPTION_JOB,

  • du temps CPU,

  • du temps système,

  • du temps total du cas-test,

  • du coût du cas-test.

Pour l’ensemble des cas-tests soumis affichage:

  • du temps CPU total,

  • du temps système total,

  • du temps total de tous les cas-tests,

  • du coût de tous les cas-tests.

_images/10004386000032700000496151743AFFA43D6D7A.svg

9.7. ccat92 : compilation des catalogues#

Compilation d’unités de catalogue dans des fichiers de commandes et d’éléments compilés.

Pas de vérification de cohérence, ni d’identité du développeur.

9.7.1. Mode d’appel#

ccat92 catalogucatalocatobj[execut[para [version [ message ]]]]

catalogu : fichier contenant les unités de catalogue à compiler.

catalo : est un répertoire en sortie qui est organisé et qui contient les sources éclatés de catalogu en éléments de CATALOGUE conforme au répertoire des versions en exploitation.

catobj : est un répertoire en sortie conforme au répertoire des versions en exploitation. catobj contient les catalogues compilés de la version version d” Aster « surchargées » par les éléments contenus dans catalogu.

execut : fichier en entrée qui contient le module exécutable qui doit effectuer la compilation de catalogu (par défaut c’est /aster/ version /execut).

para : paramètre qui vaut « prive » pour l’utilisation faite de ccat92 dans asrest et qui permet de marquer les catalogues compilés de la mention PRIVE.

version et message : définitions identiques à asno (par defaut message = message_ccat92).

9.7.2. Tâches réalisées#

Vérification que catalogu est bien du type CATALOGU (première tâche d’asno).

Eclatement des sous-catalogues dans catalo/

Si iret ≥ 4 FIN

Dans répertoire de travail établir un lien symbolique avec tous les catalogues de la version de référence.

Réaliser la “surcharge” avec les unités du fichier catalogu en recopiant les fichiers de catalo .

  • Compilation du catalogue des commandes:

  • Concaténation de tous les sous-catalogues de commande dans fort.3,

  • Assignation du fichier ‘COMMANDE_PRIVEE’ à fort.3,

  • Compilation du fichier ‘COMMANDE_PRIVEE’ avec Aster ( execut ou l’exécutable par défaut de version ),

  • Si iret  4 FIN,

Copie des messages de compilation par Aster dans message (fort.6)

Copie du fichier d’erreur (fort.9) dans message .

  • Sinon sauvegarde du résultat de la compilation des commandes dans catobj/commande.

  • Compilation du catalogue des éléments:

  • recopier compelem/grandeurs_1ere.cata dans fort.4,

  • compter le nombre de sous-catalogues dans options/ (= nb_opt ),

  • rajouter ‘OPTION_SIMPLE nb_op’ dans fort.4,

  • rajouter tous les sous-catalogues de options/ dans fort.4,

  • rajouter ‘FIN’ dans fort.4,

  • rajouter tous les sous-catalogues de typelem/ dans fort.4,

  • rajouter ‘FIN’ dans fort.4,

  • rajouter compelem/type_maille.cata dans fort.4,

  • rajouter compelem/modes_partages.cata part dans fort.4,

  • rajouter compelem/phenomenes_modelisation.cata dans fort.4.

Si version est NEW1 ou STA1 il n’y a pas de compilation avec Aster . Le résultat est juste la concaténation décrite ci-dessus.

Sinon compilation avec Aster en utilisant le catalogue de commande précédemment compilé, s’il existe.

Si iret < 4 sauvegarde du résultat de la compilation des éléments dans catobj/elements.

Sinon:

  • Copie des messages de complation par Aster dans message (fort.6).

  • Copie du fichier d’erreur (fort.9) dans message