3. Gestion de l’algorithme#

Nous allons nous intéresser à la gestion de l’algorithme. Pour gérer la convergence, les différents niveaux de boucle et les erreurs survenues lors d’un calcul, on utilise un formalisme commun, basé sur la notion d’événement .

3.1. Les différentes boucles#

Dans l’algorithme, il y a cinq niveaux de boucles <BOUC>:

<RESI>: la boucle sur les différents résidus d’équilibre demandés par l’utilisateur (RESI_GLOB_RELA, RESI_GLOB_MAXI, etc);
<NEWT>: la boucle sur les itérations de Newton;
<FIXE>: la boucle sur les points fixes (contact);
<INST>: la boucle sur les instants de calcul;
<CALC>: la boucle sur le calcul.

La «boucle» <CALC>n’en est pas vraiment une. Elle sert à gérer deux situations:

Le calcul se termine normalement (pas d’erreur) mais autrement que lorsqu’on a atteint la fin de la boucle sur les pas de temps. Pour l’instant, le seul cas est celui où le pilotage a atteint ses bornes;
Un événement est déclenché à l’extérieur de la boucle sur les pas de temps, c’est-à-dire pendant le post-traitement (détection d’instabilité par modes vibratoires);

Les différentes boucles sont réparties entre op0070, nmnewt (statique et dynamique implicite) et ndexpl (dynamique explicite). Pour la boucle sur les résidus d’équilibre, il faut regarder dans la routine nmcore, appelée par nmconv. Pour la boucle sur les points fixes, on utilise les routines nmible/nmtble, contenues dans nmnewt.

3.2. État des boucles#

L’état d’une boucle est stocké dans l’objet SDERRO(§ 2.4.2.6 ), on y accède par nmleeb et nmeceb. Il existe six états:

CONT:la boucle continue;
CONV:la boucle aconvergé (événements de type convergence et divergence);
ERRE:une erreur (événement de type erreur) est survenue pendant la boucle, on va la traiter;
EVEN:un événement (événement de type informatif) est survenu pendant la boucle;
STOP:une erreur (événement de type erreur) est survenue pendant la boucle, on s’arrête;
CTCD:état particulier de la boucle de Newton pour le contact discret;

3.3. Les événements#

On peut classer les événements selon leur origine:

Les événements définis par l’utilisateur dans DEFI_LIST_INST(par exemple, DELTA_GRANDEUR);
Les événements intrinsèques à l’algorithme: les erreurs et la convergence des différentes boucles;

3.3.1. Types des événements#

Un événement est défini par son type qui est une chaîne de caractère en deux parties <XXXX_YYYY>. La première chaîne <XXXX>décrit le type de l’événement:

Les événements donnant lieu à une erreur sont préfixéspar <ERRC_*>ou <ERRI_*>;
Les événements donnant lieu à une convergence sont préfixéspar <CONV_*>;
Les événements donnant lieu à une divergence sont préfixés par <DIVE_*>;
Les événements informatifs sont préfixés par <EVEN_*>;

La seconde chaîne <YYYY> décrit le niveau de boucle de l’événement:

Boucle sur les résidus d’équilibre <*_RESI>;
Boucle sur les itérations de Newton<*_NEWT>;
Boucle de point fixe pour le contact<*_FIXE>;
Boucle sur les pas de temps<*_INST>;

Cette information décrit dans quelle boucle les événements peuvent potentiellement se déclencher.

3.3.1.1. Événements de type erreur <ERR_>#

Des erreurs sont à traiter immédiatement (c’est-à-dire dès déclenchement de l’événement) car elles sont bloquantes pour le processus, elles sont notées <ERRI>. Les erreurs à traiter uniquement à convergence de la boucle sont notées <ERRC>.

Par exemple:

<ERRI_NEWT>est une erreur à traiter immédiatement dans une itération de Newton comme un défaut d’intégration de la loi de comportement empêche ou une matrice non factorisable;
<ERRC_NEWT>est une erreur à traiter à convergence de Newton, par exemple une sortie d’un critère physique hors des bornes de son domaine de définition;
<ERRI_FIXE>est une erreur à traiter immédiatement dans une boucle de point fixe;

Remarque:

Les erreurs typées <ERRI_CALC> entraînent l’arrêt immédiat du calcul car aucune action ne peut les traiter. Ce sont les arrêts en manque de temps CPU et l’arrêt extérieur par utilisateur.

3.3.1.2. Événements de type convergence <CONV_*>#

Les événements de type convergence se traitent à chaque niveau de boucle. Cette convergence peut-être liée à une fonctionnalité activée ou pas (cf § 2.4.1.1 ).

3.3.1.3. Événements de type divergence <DIVE_*>#

Les événements de type divergence se traitent à chaque niveau de boucle. Cette divergence peut-être liée à une fonctionnalité activée ou pas (cf § 2.4.1.1 ).

En pratique, l’état de chaque boucle est plutôt traitée en divergence. En effet, pour éviter d’avoir à vérifier qu’une fonctionnalité spécifique est active (pilotage, Deborst, contact, etc) et donc tester la convergence d’une boucle en vérifiant cette fonctionnalité, on préfère émettre un événement de divergence qu’un événement de convergence: on ne peut avoir divergence que si la fonctionnalité est activée, alors qu’on pourrait avoir convergence même si la fonctionnalité n’est pas activée.

3.3.1.4. Événements de type informatif <EVEN>#

Les événements de type informatifs sont les autres événements (ni erreur, ni convergence). Par défaut, ils ne servent qu’à donner des indications à l’utilisateur (souvent sous la forme de messages d’alarmes, le passage de RESI_GLOB_RELA à RESI_GLOB_MAXI par exemple). Certains ne sont activables que sur demande de l’utilisateur (commande DEFI_LIST_INST).

Ces événements pourront aussi être traité explicitement (autrement que par l’émission d’une alarme ou d’une information) via DEFI_LIST_INST.

Ces événements ne sont pas liés à un niveau de boucle.

3.3.1.5. Le cas des code-retour#

Un code-retour est un entier unique donnant le statut d’un opération. Il est possible de lier un événement à la valeur d’un code-retour. Chaque valeur du code-retour peut générer un événement différent, de n’importe quel type. Les codes retour -1 et 0 ont toujours le même sens:

-1: on n’a rien fait (pas de factorisation, pas d’intégration de loi de comportement, etc.);
0: on a fait quelque chose et tout s’est bien passé;

Les autres valeurs de codes retour ont un sens dépendant de leur type:

Type	Description	Signification du code
FAC	Retour de la factorisation	-1	Pas de factorisation
		0	Tout s’est bien passé
		1	La matrice est singulière
		2	La factorisation a échoué
		3	On ne sait pas dire si la matrice est singulière
PIL	Retour du pilotage	-1	Pas de pilotage
		0	Tout s’est bien passé
		1	Pas de solution de l’équation de pilotage
		2	On a atteint une borne (fin du calcul)
LDC	Retour de l’intégration de la loi de comportement	-1	Pas d’intégration du comportement
		0	Tout s’est bien passé
		1	Échec lors de l’intégration de la loi de comportement
		2	Un paramètre physique n’est pas dans son domaine de définition
		3	La contrainte SIZZn’est pas nulle (algorithme de De Borst)
CTC	Retour du traitement du contact discret	-1	Pas de contact discret
		0	Tout s’est bien passé
		1	Le nombre maximum d’itérations de contact a été atteint
		2	La matrice du contact est singulière

3.4. Gestion des événements#

3.4.1. Modification, ajout ou suppression d’un événement#

La plupart des événements standardisés sont prévus dans la structure de données et les utilitaires qui y sont liés. Dans la plupart des cas, il ne s’agit de modifier que la routine nmcrga (voir § 2.4.2.6 en y ajoutant la caractéristique du l’événement dans les DATA en début de routine.

Description	DATA
Nom de l’événement	NEVEN
Nom du code-retour lié à l’événement (XXX si pas code-retour)	NCRET
Valeur du code-retour lié à l’événement (99 si pas code-retour)	VCRET
Type et niveau de déclenchement de l’événement	TEVEN
Fonctionnalité activant un événement de type convergence ou divergence	FEVEN
Code du message à afficher quand l’événement se déclenche	MEVEN

Le système de vérification des messages fait que le code du message à afficher (MEVEN) n’est pas suffisant, il faut aussi impacter nmevim.

3.4.2. Émissions des événements#

Pour déclencher un événement le développeur doit le prévoir dans l’algorithme en appelant la routine nmcrel. Par exemple:

Commande	Effet
CALL NMCREL(SDERRO,”ERRE_TIMN”,.TRUE.)	Manque de temps CPU pendant une itération de Newton
CALL NMCREL(SDERRO,”RESI_MAXR”,.TRUE.)	Passage de RESI_GLOB_RELAà RESI_GLOB_MAXI
CALL NMCREL(SDERRO,”DIVE_FIXG”,.FALSE.)	Pas de divergence de la boucle de point fixe sur la géométrie

Si l’événement est de type <ERRI_BOUC>, le statut de la boucle <BOUC> est automatiquement modifié. C’est une précaution pour éviter que le développeur oublie de traiter l’événement (et donc risque de provoquer des résultats faux). Une erreur immédiate de niveau <ERRI> est répercutée à tous les niveaux de boucle pour les mêmes raisons.

Pour activer un événement lié à un code-retour, il faut utiliser la routine nmcret au lieu de nmcrel. Par exemple CALL NMCRET(SDERRO,”LDC”,LDCCVG) s’occupe de transformer en événement la valeur du code retour de la loi de comportement.

3.4.3. Traitement des événements#

L’idée principale est de traiter les événements à tous les niveaux de boucle, de changer l’état des boucles selon le résultat de ce traitement.

3.4.3.1. Événements de type convergence et divergence#

Les événements de type convergence ou divergence sont examinés à chaque niveau de boucle, dans une routine dédiée appelée nmevcv . Cette routine modifie l’état de la boucle :

On suppose initialement que la boucle continue (état CONT, cf § 3.2 )
On boucle sur les événementsde type <CONV_*>et <DIVE_*>en prenant en compte des éventuellesfonctionnalitésactivées;
On calcule l’état résultat pour ce niveau deboucle: si tous les événementsde divergence sontfaux et tous les événementsde convergencesontvrais, alors ce niveau de boucle est dans l’état convergé;
On vérifie les états de convergence des boucles intérieures à ce niveau. Pour que l’état final de cette boucle soit convergé, toutes les boucles intérieures doivent être convergées. Si c’est le cas, la boucle passe dans l’état convergé (état CONV, cf § 3.2 )
On modifie l’état de la boucle courante en appelant la routine nmeceb;
La routine nmecebtransmet l’état de la boucle aux boucles supérieures (évite les erreurs non-traitées);

Boucle	Code	Routine	Routine appelante
Résidus	RESI	nmcvgr	nmconv
Newton	NEWT	nmcvgn	nmnewt
Point fixe	FIXE	nmcvgf	nmtble
Pas de temps	INST	nmcvgp	op0070
Calcul	CALC	nmcvgc	op0070

3.4.3.2. Événements de type erreurs#

Les événements de type erreur sont particulièrementsensibles et doivent être traités de manière très rigoureuse pouréviter les résultatsfaux. En premier lieu, l’événementde type erreur a été émis par le biais des routines standards: nmcrelet nmcret. On rappelle que dans le cas des événements erreur, on modifie systématiquement l’état de la boucle en mode ERREdans l’optique d’éviter de continuer ces boucles si jamais l’erreur n’a pas été traitée convenablement par l’algorithme (oubli du développeur).

De manière systématique, les événements de type erreur sont testés dans l’algorithme via la routine nmltev. Si un événement de type erreur est activé, un GOTO est immédiatement fait dans le programme.