1. Introduction#
Etude numérique
Pour réaliser une étude numérique avec Code_Aster , l’utilisateur final déclenche les fonctionnalités du code et fournit les informations nécessaires à l’exécution de ces fonctionnalités.
Une fonctionnalité est sélectionnée par l’intermédiaire d’une commande. Une commande est d’abord un nomc’est-à-dire une chaîne de caractère ou encore un identifiant externe (connu de l’utilisateur) de la fonctionnalité. Elle agrège également des attributs et en premier lieu l’identifiant interne de la fonctionnalité (exploitable par le code Fortran).
Les informations nécessaires au lancement et à l’exécution de la commande autrement-dit les paramètres du traitement numérique, sont des données introduites au moyen de mots-clés les identifiant. Pour une commande donnée, un certain nombre de paramètres doivent être définis.
La description des commandes et des mots-clés est effectuée par les développeurs de Code_Aster . dans un fichier appelé «catalogue des commandes».
L’utilisateur final utilise le code via un fichier appelé «fichier de commande». Il y fournit des commandes dont la composition doit être compatible avec leur description dans le catalogue des commandes. Les commandes sont nombreuses mais le nombre de données associées est beaucoup plus important avec des combinaisons possibles elles-mêmes très nombreuses.
Enfin le code de calcul stocke les informations (commandes et mots-clés) dans une structure de données interne appelée «jeu de commande».
Le rôle du superviseur
Le superviseur est la partie de Code_Aster qui gère le jeu de commande. En particulier:
il importe le catalogue des commandes dans la mémoire Python,
il charge les commandes et leurs mots-clés dans la mémoire Python,
il exécute le traitement commande par commande,
il fournit - à la demande du Fortran – la valeur des paramètres aux fonctionnalités de Code_Aster . stockées dans la mémoire Python. Pour cela le superviseur propose une API C.
L’interface graphique Eficas
Il est possible de définir «manuellement» son fichier de commandes, par exemple au moyen d’un éditeur de texte. Toutefois, l’utilisateur non familier avec la syntaxe des commandes qu’il manipule mais aussi le langage python pourra utiliser Eficas.
L’interface graphique Eficas est destinée à l’utilisateur final de Code_Aster . Elle lui permet de construire des commandes valides avec des mots-clés associés eux aussi validés statiquement, puis de générer un fichier de commande à destination du code. L’utilisateur a l’assurance que le fichier produit par Eficas a une syntaxe correcte.
Le noyau
Les sources communes à l’interface-graphique Eficas et le superviseur de Code_Aster sont organisées (identifiées et regroupées) dans un espace de développement spécifique appelé le«Noyau». La compréhension de ces sources est évidemment une condition nécessaire pour entreprendre la maintenance des deux outils qui les utilisent.
Les principaux acteurs
Les principaux types d’acteurs évoluant dans l’environnement d’Eficas et du superviseur sontlistés ci‑dessous.
L’utilisateur final: il connaît plutôt la partie physique du problème à résoudre et il a pour tâche d’introduire des données valides dans le code, de lancer des calculs et de dépouiller les résultats; il peut utiliser l’interface graphique Eficas pour cela.
Le développeur de fonctionnalités dans Code_Aster : il pratique essentiellement la programmation Fortran des algorithmes numériques et, dans le cas d’une macro-commande, la rédaction du script Python correspondant ; il enrichit et/ou modifie le catalogue de commande et il utilise l’API C du superviseur pour récupérer dans son code Fortran, les valeurs fournies par l’utilisateur final.
Le développeur du superviseur dans Code_Aster : il rédige les scripts de lecture et d’interprétation du catalogue de commandes et du jeu de commandes; il s’occupe également du module python aster écrit en C (astermodule.c) qui sert d’API au superviseur.
Le responsable de la maintenance du code, de l’environnement d’utilisation et de la gestion de configuration: il centralise les sources. En plus du code Fortran, ces sources comprennent celles du catalogue (Python) des commandes, les scripts (Python) du superviseur et celles du module aster.
Le développeur de l’interface graphique Eficas développe une interface homme-machine. Son rôle est de concevoir et de programmer des boîtes de dialogue ainsi que des enchaînements d’événement permettant la prise en compte des requêtes de l’utilisateur final et la vérification – à chaque instant - de la validité du jeu de commandes en cours de construction.
Dans ce document, on met plutôt l’accent sur les principes de la conception du noyauque sur le détail des scripts dont on ne peut économiser l’examen.
Sujets traités
Le premier chapitre propose une définition sommaire des termes utilisés abondamment dans la suite du document.
Le chapitre 2 présente les quelques conventions et l’organisation des fichiers sources en répertoires: les packages. Il décrit également l’environnement nécessaire au développement et au fonctionnement du superviseur de Code_Aster et de l’interface graphique Eficas.
Dans le chapitre 3, quelques rappels sont effectués sur le langage de script Python. Ils doivent orienter le futur responsable de la maintenance vers certaines techniques qu’il lui faudra maîtriser pour effectuer sa tâche.
L’important sujet de la factory de commande est évoqué au chapitre 4 . C’est une base nécessaire à la compréhension de toute la structure du jeu de commande.
Enfin, une réponse est apportée au chapitre 5 , à quelques questions dont on peut prévoir que tout futur responsable de la maintenance pourra se poser.
1.1. Définitions#
Mode «par lot»
Le processus de traitement des commandes utilisateur par le Code_Aster peut s’effectuer suivant deux modes.
Dans le premier mode, le fichier commande est chargé en mémoire pour créer le jeu de commandes. Cette création du jdc permet de valider la syntaxe python (parenthèses, virgules), la syntaxe Aster (cohérence avec le catalogue) et de valider les concepts passés en argument. Enfin après cette vérification, le jeu de commande est parcouru pour effectuer les traitements numériques correspondants.
Ce premier mode est appelé «mode par lot». L’utilisateur final sélectionne ce mode en spécifiant la valeur ’OUI’ pour le mot-clé PAR_LOT sous la commande DEBUT.
Dans le second mode, le fichier de commande est chargé en mémoire pour créer le jeu de commandes. Puis les étapes (équivalentes aux commandes) sont construites et exécutées séquentiellement.
L’utilisateur final sélectionne ce mode en spécifiant la valeur ’NON’ pour le mot-clé PAR_LOT sous la commande DEBUT.
Par défaut, le mode utilisée est PAR_LOT=’OUI’.
Opérateur de Code_Aster
Un opérateur est une unité de Code_Aster prenant en charge une fonctionnalité du code. Concrètement c’est un sous-programme Fortran dont le nom est numéroté, par exemple la subroutine OP0001 qui charge un maillage dans la mémoire de l’application. La numérotation des opérateurs facilite l’association entre leur représentation interne (sous-programme Fortran) et leur représentation externe pour l’utilisateur final (commande).
Commande
Une commande est une chaîne de caractères identifiant un opérateur numérique. Elle permet donc à l’utilisateur final de déclencher l’exécution de cet opérateur à partir d’un fichier de données appelé «fichier de commande».
Il existe 4 types de commandes: OPER, PROC, MACRO et FORMULE.
Le développeur de l’opérateur numérique définit - dans le catalogue de la commande - les caractéristiques de la commande et celles des mot-clés correspondant aux paramètres de l’opérateur numérique:
son nom (la chaîne de caractères utilisable par l’utilisateur final),
ses règles de composition en mots-clés,
un commentaire explicatif en anglais et/ou en français,
la clé définissant le manuel et le chapitre consacré à ce mot-clé dans la documentation de Code_Aster .
Commande OPER
En plus des attributs énumérés ci-dessus, une commande de type OPER possède l’attribut suivant:
Le type de la structure de données Aster produite par l’opérateur et retournée par la commande;
Commande PROC
Une commande de type PROC a la caractéristique de ne pas retourner une valeur. Cette particularité mise à part, elle possède les mêmes attributs qu’une commande de type OPER.
Commande MACRO
Une macro est une fonction écrite en Python – par le développeur Aster - qui appelle des commandes – c’est-à-dire des opérateurs - de Code_Aster . Elle stocke des résultats qui pourront être récupérés via le superviseur.
Le texte de la macro peut être public; dans ce cas il est stocké dans un fichier spécifique du sous‑répertoire Macro. S’il est privé, il est placé ou importé dans le fichier de commande.
Une commande de type MACRO permet à l’utilisateur final d’utiliser la macro. Par exemple la commande ASSEMBLAGE permet de lancer la macro publique assemblage_ops.
Catalogue d’une commande
Le catalogue d’une commande est l’ensemble des instructions Python décrivant la définition de la commande c’est-à-dire les valeurs affectées aux attributs de la commande.
Le catalogue d’une commande est écrit par le développeur de l’opérateur numérique associé à la commande.
Catalogue général
Le catalogue général est un fichier Python contenant la description de toutes les commandes autrement-dit contenant les catalogues de toutes les commandes.
Jeu de commande
Le jeu de commande est la structure de données - organisée dans un objet Python – contenant l’ensemble des informations fournies par l’utilisateur final, dans le fichier de commande.
Fichier de commande
Le fichier de commande permet à l’utilisateur final de déclencher les opérateurs numériques portant les fonctionnalités de Code_Aster par l’intermédiaire des commandes.
Structure de donnée Aster
Une structure de données Aster est une organisation de données produites par un opérateur numérique de Code_Aster . Elle est identifiée par un type lui-même déclaré au début du catalogue (cata.py); ce qui permet de l’utiliser – symboliquement – dans le fichier de commande bien qu’elle soit produite par du Fortran.
Mot-clé simple
Un mot-clé simple est une chaîne de caractères identifiant une donnée utilisée en entrée par un opérateur (une fonctionnalité numérique de Code_Aster ). Un mot-clé simple est donc défini à l’intérieur d’une commande de Code_Aster .
L’utilisateur final pourra fournir une valeur au paramètre d’une commande par l’intermédiaire du nom du mot-clé simple correspondant dans le fichier de commande.
Le développeur de fonctionnalité de Code_Aster définira quant à lui, les caractéristiques du mot-clé simple dans le catalogue de la commande contenant le mot-clé simple:
son nom (la chaîne de caractères utilisable par l’utilisateur final et par l’opérateur numérique),
le type du paramètre (entier, réel, texte, concept, …),
le statut du mot-clé simple (facultatif ou obligatoire),
la valeur par défaut à affecter au paramètre,
le nombre minimum de données que l’utilisateur final devra fournir derrière le mot-clé simple,
le nombre maximum de données que l’utilisateur final devra fournir derrière le mot-clé simple,
un commentaire explicatif en anglais et/ou en français.
Le superviseur de Code_Aster charge dans la mémoire de l’application, les caractéristiques du mot-clé simple, à partir du catalogue des commandes. Puis il charge (et vérifie) éventuellement la valeur du paramètre de la commande à partir du fichier de commande fourni à l’application par l’utilisateur final.
L’opérateur numérique de Code_Aster interroge le superviseur via l’API getvxx pour récupérer la valeur du paramètre à partir du nom du mot-clé. Le superviseur retourne la valeur fournie par l’utilisateur ou la valeur par défaut du paramètre.
Mot-clé facteur
Un mot-clé facteur est une chaîne de caractères identifiant un groupe de mot-clés simples sémantiquement associés. Un mot-clé facteur est défini à l’intérieur d’une commande. Une commande peut contenir plusieurs mots-clés facteurs éventuellement optionnels., chaque mot-clé facteur contenant lui-même des mots-clés simples de même nom.
L’utilisateur final pourra définir dans son fichier de commandes, un mot-clé facteur en spécifiant son nom puis sa valeur c’est-à-dire la valeur des paramètres numériques définis derrière les mots-clés simples du mot-clé facteur.
Le développeur de la fonctionnalité de Code_Aster définit les caractéristiques du mot-clé facteur dans le catalogue de la commande contenant le mot-clé facteur:
son nom (la chaîne de caractères utilisable par l’utilisateur final et par l’opérateur numérique),
ses règles de composition en mots-clés simples,
le statut du mot-clé facteur (facultatif ou obligatoire),
le nombre minimum de répétition du mot-clé facteur,
le nombre maximum de répétition du mot-clé facteur,
un commentaire explicatif en anglais et/ou en français,
la clé définissant le manuel et le chapitre consacré à ce mot-clé dans la documentation de Code_Aster .
Bloc conditionnel
Un bloc conditionnel (un bloc), associe:
des mots-clés simples,
des mots-clés facteurs,
et des blocs conditionnels.
L’occurrence du bloc dans sa commande, dépend d’une condition exprimée lors de la définition de la commande par le développeur de la fonctionnalité numérique.
Le développeur de l’opérateur correspondant à la commande contenant le bloc, spécifie les caractéristiques du bloc:
son nom,
sa condition,
ses règles de composition en mots-clés simples,
un commentaire explicatif en anglais et/ou en français.
L’utilisateur final pourra donner une valeur aux paramètres du traitement en utilisant les mots-clés facteurs et les mots-clés simples associés dans le bloc conditionnel mais sans spécifier le nom du bloc.
Règle de composition
Les entités composites du catalogue de commandes telles que «jeu de commandes», commande, mot-clé facteur et bloc conditionnel, structurent d’autres entités en suivant éventuellement une ou plusieurs règles de composition parmi les suivantes:
AU_MOINS_UN
La règle AU_MOINS_UN exprime que l’une au moins des entités dont les noms sont passés en arguments doit être présente dans l’entité composite dans laquelle figure la règle.
UN_PARMI
La règle UN_PARMI exprime que l’une et une seule des entités des entités dont les noms sont passés en arguments doit être présente dans l’entité composite dans laquelle figure la règle.
EXCLUS
La règle EXCLUS exprime que si l’une des entités dont le nom est passé en argument, est présente, les entités correspondant aux autres arguments doivent être absentes dans l’entité composée dans laquelle figure la règle. Autrement-dit si plusieurs entités du groupe sont présentes la règle est violée.
ENSEMBLE
La règle ENSEMBLE exprime que si l’une des entités dont le nom est passé en argument est présente dans l’entité composée, alors toutes celles correspondant aux autres noms devront l’être aussi. L’ordre des occurrences n’a pas d’importance. Et si aucune des entités représentées dans la règle n’est présente dans l’entité composite, l’entité composite est valide.
PRESENT_PRESENT
La règle PRESENT_PRESENT exprime que si l’entité correspondant au premier nom est présente, alors toutes celles correspondant aux autres noms devront l’être aussi dans l’entité composite courante. L’ordre d’occurrence des autres entités n’a pas d’importance. Si aucune des entités représentées dans la règle n’est présente, l’entité composite est valide.
PRESENT_ABSENT
La règle PRESENT_ABSENT exprime que si l’entité correspondant au premier nom est présente, alors toutes celles correspondant aux autres noms devront être absentes dans l’entité composite courante. L’ordre d’occurrence des autres entités n’a pas d’importance. Si aucune des entités représentées dans la règle n’est présente, l’entité composite est valide.
Chaque règle de composition (appelée aussi simplement «règle») est une classe (voir le module regle.py).
1.2. Prise en charge de la maintenance#
La démarche suivante est proposée au candidat à la maintenance de l’interface graphique Eficas et/ou du superviseur de Code_Aster .
Etudier «Accas» c’est-à-dire ce qui est commun à l’interface graphique Eficas et au superviseur de Code_Aster ;
Etudier la structure du catalogue général des commandes: dans le fichier catalogue et dans la mémoire de l’application. Pour cela:
se familiariser aux techniques de programmation en Python, utilisées dans Accas;
développer une petite maquette de factory (cf. [§ 4.1 ]) pour bien intégrer le mécanisme de base du chargement des mots-clés.
Etudier la structure du jeu de commandes (dans son fichier) et dans la mémoire; en particulier la question du chargement du jeu de commande (mécanisme et zones de codes concernées) doit être considérée;
Examiner les scripts Python ou les sources C mis en jeu à l’occasion de demandes de modification ou de traitement des erreurs détectées par les utilisateurs.